Cloud Migration Strategy (High Level)

The task of migrating applications to the public cloud is perhaps the most daunting part of the cloud and/or digital transformation strategy. This short article tries to present a (overly) simplistic approach:

Application Portfolio Review (Refer to the left side of the above diagram)

The first step of a cloud migration project starts with the Application Portfolio Review. High level steps as follows:

1.      List down the list of existing applications (Existing Portfolio).

2.      List down the list of applications in the final state after the cloud/digital transformation (Target Portfolio). This takes into account rationalisation & modernisation of existing applications, and planning of new business capabilities to be acquired. Typically an Enterprise Architecture project might be required to comprehensively form this view of the Target Portfolio.

3.      With the Existing Portfolio and Target Portfolio detailed, there will be 3 buckets:

a.      Applications under Existing Portfolio but not in the Target Portfolio – Retire them.

b.      Applications under Target Portfolio but not in Existing Portfolio – These are the new applications that will be created. Adopt a PaaS approach for in-house development, and a SaaS approach for product based implementation (refer to my other article).

c.      Applications under both Existing Portfolio and Target Portfolio – These are existing applications that needs to be rationalised and modernised.

- For product based applications – Repurchase as SaaS (where possible, else fall back to IaaS)

- For in-house development – Refactor as PaaS (where possible, else fall back to IaaS)

  - For legacy that are really not worth modernising, but yet they are still serving an essential business function – Rehost as IaaS

?Application Migration Plan (Refer to the right side of the above diagram)

After the portfolio review, each application’s migration approach will be classified into Retire, Rehost, Refactor, Repurchase, PaaS, and SaaS. More detailed discussion and planning will then be required to put a time frame into the migration plan (the number in the blue bubble).

Generally, for new applications, they will follow their project schedule. For applications that needs to be rationalised and modernised, the trigger will come from either system EOSL planning, or major application upgrade plans.

I am sure this article overly simplified the migration planning required, but I hope that it serves as a starting point for anyone to develop into a more complete framework.