Running a cloud migration project can feel like navigating choppy waters, requiring IT teams to make their way through a huge variety of crashing, interconnected forces.
In truth, it somewhat is. There is a massive weight of compute engines, database layering, analytics tooling, and machine-accelerated engineering to bring forward and apply to an organisation’s existing and incumbent IT stack.
It makes practical sense then to take a more refined approach to both SAP and non-SAP cloud migration and clearly define the strategic steps needed to achieve the anticipated tactical cloud advantages.
Nobody wants the journey to cloud to be beset with lift-and-shift clunkiness or rip-and-replace clumsiness, so a phased approach is the best route to cloud migration that will ultimately deliver outstanding business outcomes and great user/customer experiences.
It is considered a best-practice approach to use the following phases:
• Mobilise & Design
• Technical Foundation
• Deploy & Migrate
• Operate & Optimise
Let’s take these phases in turn and think about how phased progression can enable enterprise IT teams to come out of their migration initiatives pleasingly unfazed and in the zone.
Phase 1: Mobilise & Design
The Mobilise & Design phase involves bringing the right team to the customer, to identify the interdependencies between different Line of Business (LoB) functions and the IT services they need to operate effectively.
Throughout the course of several workshops, it is important to analyse and collect business requirements and present the technical design and programme approach documents to the customer, ready for review and signoff.
For both SAP and non-SAP systems, it is important to settle upon a migration approach and pattern. You can envisage the shape of this process if you think about the seven ‘Rs’ of cloud migration: Rehost, Relocate, Replatform, Repurchase, Refactor, Retain and Retire.
Design also includes discovery. This is the process used to identify the interdependencies between an enterprise’s applications. We often find that not all interfaces are fully documented, which means that neither the business nor the IT department can provide all the required technical details. Minor oversights at this stage have the potential of significant impact and cost further down the line, so it’s important to leave no stone unturned.
With the data that is automatically captured during the discovery, it is possible to build an integration catalogue which will be a key input document for the third stage, the Deploy & Migrate phase.
Phase 2: Technical Foundation
In the Technical Foundation phase, the output of the Mobilise & Design phase must be used as input. That is why it is critical to the overall success of the project for a customer to bring the right people into the previous Mobilise & Design phase, so that this second phase is all about executing and delivering what has been designed and signed-off.
At this stage, it’s important to think about the deployment of the software in terms of what we might call its ‘landing zone’ – its post-production live deployment phase. Key operational on-the-ground equipment needed to traverse the landing zone effectively includes the scope of the target architecture build, naming conventions and nomenclature and details relating to mandatory toolsets, tagging, security compliance, data protection and governance.
Phase 3: Deploy & Migrate
A standard approach will be to start with non-critical systems, such as any that are at the sandbox stage, or supporting applications. As prescribed as this sounds, the finer details really depend on the migration approach set in the Mobilise & Design phase, which will drive the sequence of the migration.
This phase is all about using best-in-class systems to automate the deployment of the target environments and to actually migrate the systems from the source location (which can be anything in terms of pre-existing compute resource) to cloud (AWS, Azure and/or GCP).
Throughout the migration phase, a runbook is maintained so that the lessons learned from each tier are captured for onward use in the next tier. Also, after a tier has been migrated onto cloud, the project team will then hand over the migrated systems to the operations team. This ensures there is a clean and clear early life support factor during the project to avoid any ‘throwing-over-the-wall-and-run’ scenarios.
When we reach the production systems stage, it is a smooth, very controlled and predicted cutover/go-live.
Phase 4: Operate & Optimise
This is the phase where a highly skilled and experienced team looks after the systems on cloud to ensure that the service levels which are agreed in the signed Service Delivery Catalogue (SDC) can be met. An SDC should be flexible enough to accommodate for any nuances of customer. This phase is also the ideal time to simultaneously present and discuss innovation and optimisation options.
Last and most important, during the Operate & Optimise phase, your business will gain and continuously realise the value of operating workloads in the cloud. But remember, whilst some feel the migration phase requires the greatest attention to detail, the companies that gain most from SAP on cloud ensure that plans for the Operate phase are front and centre as they go through their journey of moving SAP to the cloud. This focus on the final operate phase during the migrate phase has a broad and significant impact across all aspects of your IT systems.
