A while ago I saw a kinda flow chart / subway map entailing the various paths to migrate your workloads to the cloud. My personal view on the matter differed slightly from this, so I’ve mocked up my own version…
The various tracks ;
- “Retire” ; For the workloads that are not relevant anymore to the business… decommission them.
- “Re-Host” ; A typical “lift & shift” scenario where you move the system “as-is” to the cloud.
- Variant “Manual” ; Tedious effort… doing a manual rebuild of your systems in the cloud.
- Variant “Automated” ; Work via migration tooling or redirect your automated deployments.
- “Re-Purchase” ; Some applications are not compatible with cloud platforms. Therefore it might sometimes be interesting to purchase another software suite. Where you’ll join the manual track once the implementation starts…
- “Re-Platform” ; Cloud provider typically offer “PaaS”-services too, where an On Premises deployment only favors “IaaS”-thinking. Examples here ; IIS on premises vs Webapps in the cloud.
- “Re-Architect” ; If you have control over your application, you might consider to refactor it towards cloud native components. Given, this is not always an easy/cheap task, but it’s a play considering the long term.
But for all, it starts with ;
- Discover ; Identify all the workloads in your IT landscape.
- Assess ; Investigate their readiness towards the cloud and which migration paths are viable.
And “ends” with ;
- Validate ; After a “construct” / “deploy”, always validate (test) if everything is according to your expectations / specifications.
- Transition ; Never forget to ensure that your operational team is ready before the “go live” of your workload.
- Go-Live ; The moment your customers will use the workload. 🙂