AWS Migration best practices - Agile vs. Waterfall?

Changes ahead

The industry has changed a lot over the years, and we have seen in particular massive progress with endless resources that have failed to succeed. There is an abundance set of tools, of methodologies, tons of documented experiences but yet fundamentally the needle has not shifted. But how can this be? Shouldn’t we be much smarter in managing programs with all the tools and methodologies in hand? From V model, Prince 2, to Agile, to … ?

In principle and on paper yes, but despite the tools, despite all of the different methodologies and disciplines of project management, the outcome - in particular of large scale projects such as data center migrations and consolidates programs - has barely changed.

At least, that’s what all the research and all the indicators seem to show us. However, we also know that good project, programme and portfolio management can work, because there are certain industries – interesting enough very often outside IT – which successfully manage projects in line with best practices. For example, the building trade. It’s just not possible to build a skyscraper from scratch without having plan which is fit for purpose, that’s practical and which meets the typical constraints of programmes such as time, resources, what ever …

Planning is everything, the plan is nothing

And that’s where it all starts easily to go wrong. To have a plan at enough detail that represents the actual task to be done can become a very difficult thing for most organizations who want to work in an agile format. But how do we get out of this dilemma? The solution is quite simple: Build a high-level masterplan, define a set of key milestones with underlying deliverables as a governance framework, but allow project teams to work agile within their sub-projects.

Practical application

And this is exactly why we have introduced this approach in a data center consolidation program for a former client of us – a global acting private and investment bank, which has signed a large outsourcing contract with a systems integrator.

A year later the deal was in deep trouble and literally out of control. There were plenty of independent migration plans in multiple qualities [from very detailed to high level], but there was no high-level plan, that married up those independent plans. The absence of the high level plan fundamentally meant there was not a clear understanding of everything that have to be done, the time by which it had to be done, and the dependencies that existed around it.

To succeed, we came to conclusion that we needed to define highly standardized template migration plans [different for small, medium, and large migrations], covering migration preparation and execution phases. Then we have invited team by team to a kick-off session, explained the concept and agreed binding delivery dates as per template plans.

Once these individual plans have been linked with the high-level migration plan, we have simply tracked progress against the high-level plan [overall migration schedule], until 1,400+ applications have been successfully migrated. However, and to keep things simple, we have not taken care about how teams have tracked progress of their individual plans themselves [agile, waterfall, whatever …] thus avoiding unnecessary bureaucracy.

One plan to rule them all

And this is – taken data center consolidations and migration programs into consideration – very similar to what AWS has introduced as part of their migration best practices:

The guys have built a migration framework and broken down migration projects into three independent building blocks, starting with the assess phase, followed by the mobilize and finally by the migrate and optimize phase [I will share with you further insights regard AWS migration frameworks and best practices, share our experiences when working against these frameworks in another blog].

Overkill?

But isn’t this an overkill? At the first glance yes, but at the second glance obviously no and the rule of thumb is quite simple as well: As better you plan upfront, as more you think about potential risks and mitigations upfront, as less issues you will face during your migration phases. And to fail during migrations is for sure not an option for businesses at all.

Overview

1. High Level Program Plan
   • Waterfall methodology
   • Executive Level Steering Committee’s
     • Informed by Program Management about progress
     • Agile does not work for them
2. Governance Framework
   • PMO
     • Project teams are governed by Program Management
     • but not micromanaged based on templated migration plans [frameworks] issued by Program Management
3. Agile
   • Project teams
     • responsible for migration preparation
     • and execution of systems owned by them manage themselves
     • up to them to chose project management methodology of choice