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:

MAP

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

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

Similar Posts You Might Enjoy

AWS Certification Challenge - jetzt den CloudPractitioner machen!

Get certified challenge - Ein Meetup der AWS User Group Hannover Wir haben uns entschieden, die User Group in Hannover wieder in deutscher Sprache zu halten. Daher dieser Post auch in Deutsch. The orga team of the AWS User Group Hannover (Malte&Me) decided to get back to german language in the user group, so this post is in german. Einladung Einstieg in die Zertifizierung zum AWS Certified Cloud Practitioner: Wie geht das, Tipps, wie lernt man…. - by Gernot Glawe

Jump to the Cloud - Migration Immersion Day

Der Sprung in die Cloud - unterstützt durch unsere Migrationserfahrung. In diesem Video beschreiben wir den Weg zu erfolgreichen Migrationen in Richtung AWS. Wir geben einen Überblick über die Phasen des Migrationsprozesses: Assess Mobilize Migration & Modernization Dabei konzentrieren wir uns auf die gemeinsamen Herausforderungen im Migrationsprozess und deren Bewältigung. Darüber hinaus zeigen wir Werkzeuge und Methoden, die Ihnen helfen können, schneller zu migrieren und Sie in jeder Phase dieses Prozesses zu unterstützen. Die Aufzeichnung ist in deutscher Sprache. Speaker: Andreas Tschauner und Gernot Glawe Das Lab wird in einem separatem Video gezeigt. Die Fragerunde ist nicht Bestandteil des Videos. - by Andreas Tschauner , Gernot Glawe

People perspective of cloud transformation

The underestimated factor The underestimated human factor in migrations to the Amazon Web Services (AWS) cloud. You want to migrate (your IT) to the Cloud! This is not only a complex technical task. Let’s call it “SoftSkills”, “peopleware”, “social systems” - it’s all about people. Their thoughts, feelings and the resulting behaviour make a migration a success. Or not. - by Petra Rosemeier , Gernot Glawe