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

1. Articulating the vision so everyone understood the “why” of the programme

2. Quantifying the business case so it was clear how it was going to succeed

3. Estimating, sequencing and planning the migration using multiple scenarios so the team knew where to start and what they were getting into

4. Analysing Risks and Issues so early stage mitigations could be planned reducing risk

5. 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

1. Designing Security so that all applications were secure “out of the box”

2. Application architecture, dataflows and cross cutting concerns so it was clear what was being built

3. Technical proofs of concept so that high priority applications could be moved

4. 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.