Azure Cloud Migration Programme Shaping
Background
Many organisations are trying to achieve the benefits of moving their application inventories to the public cloud and therefore decommissioning as much of the internal infrastructure as possible. Obviously depending on the size of the inventory these are significant programmes with board level attention.
A reinsurance investment manager had selected Microsoft Azure as their Cloud Service Provider (CSP) and was interested in starting the programme to migrate their 90 applications. They were trying to achieve
More business agility
Lower run the firm costs
Higher degree of standardisation across the landscape reducing operational risk
Improved security and compliance
Better decision making through more informed cost management
Alongside the cloud migration programme there was also a programme to re-architect some of the applications breaking them down into microservices and containerising them.
Unfortunately, with cloud migration programmes and concurrent overlapping programmes there is a large risk of missing these benefits and so they needed help shaping their programme and putting it on solid foundations.
The Project
The methodology used two tracks to de-risk the programme:
1. Programme Design
Articulating the vision so everyone understood the “why” of the programme
Quantifying the business case so it was clear how it was going to succeed
Estimating, sequencing and planning the migration using multiple scenarios so the team knew where to start and what they were getting into
Analysing Risks and Issues so early stage mitigations could be planned reducing risk
Stakeholder analysis and mapping so they understood how the change management would work (e.g. where were the points of resistance)
The deliverables from the Programme Design were shared with the board allowing them to select the scenario they wanted
2. Technical Due Diligence
Designing Security so that all applications were secure “out of the box”
Application architecture, dataflows and cross cutting concerns so it was clear what was being built
Technical proofs of concept so that high priority applications could be moved
Continuous Delivery tool chain developed so that standardised development processes could be rolled out across the development teams
The deliverables from this Technical Due Diligence were shared with all the teams allowing them to feel part of the change and make early progress with the first applications
The Outcome
During the programme the two concurrent programmes were merged into one to avoid dependency paralysis.
The board were able to understand what the programme was delivering, how much it was likely to cost and when it was likely to pay back in each scenario and thus select their preferred one.
The first application was engaged halfway through this shaping phase allowing an early start on the technical stream after two proof of concepts had been built
As a result of this shaping phase the programme was able to start confidently and safely.