Organizations have different business objectives when it comes to migrating to the cloud. Most drivers behind cloud transformation initiatives are attributed to market viability and competitiveness as moving to the cloud promises scalability, flexibility, and cost-effective infrastructure. It's no longer news to hear about organizations making the move. However, we've seen a gap in real-time projects while implementing cloud migrations end-to-end in the simplest and fastest way possible which is why we introduced the 5D's of IT-Conductor's Cloud Migration Strategy.
Moving systems to the cloud (Azure, AWS, GCP, etc.) can be as complex as it can be if you don't have the right strategy and tools. However, following a set of best practices will help you ensure a smooth transition.
On a broad basis, we can divide the Cloud Migration tasks into 3 phases: Pre-migration, Migration (cutover), and Post-migration.
1. Set your business objectives with the end in mind.
Evaluate potential benefits, opportunities, and risks associated with moving resources to the cloud. Brainstorm ideas on how operations will take shape in your target cloud infrastructure.
You need to have High-Level Design (HLD) and Low-Level Design (LLD) which should include network design, systems interconnections, project plan, firewall port details, etc.
When you envision operations upfront, you get to see the bigger picture of what your day-to-day would look like after migration, and you're off to a good start.
2. Have a clear understanding of all IT assets you currently have in your environment.
Especially in large organizations where workloads are often interdependent, it is important to have a complete understanding of how each IT asset relates to other components. We need to deeply study the source systems and understand how they are connected and communicate with other SAP and Non-SAP (3rd party) systems. This is made possible through application discovery with the use of tools capable of discovering deep dependency chains in an application environment.
3. Determine what applications and workloads to include in the migration and plan out a strategy on how to go about moving them to the cloud.
It's best to start with standalone systems first then work your way up from low-risk systems to mission-critical applications. You can also perform multiple Proof of Concept (POC) in a sandbox system before performing actual changes in the live systems. Evaluate their impact on day-to-day operations, service level agreements (SLAs), costs, and other compliance requirements. For each system and/or application you plan to migrate, understand how migrating them will affect processes and assess whether moving them to the cloud meets the objectives you've initially defined.
4. Build cloud competencies and start training people early in the process.
This way, you can make informed decisions about which applications and services to migrate and how best to do it. Wrong decisions can lead to data loss, high-impacting downtime, and frustration for your customers. But don't worry if this sounds impractical for your organization at the moment. Later on, you'll see how our solution best fits organizations wanting to move as simple and fast as possible.
5. Document separation of duties (SOD) and incorporate access and security controls.
Cloud migration projects usually involve several teams, but not everyone should have access to everything. Only give access to specific individuals or teams responsible for a particular application, component, or activity. By incorporating appropriate controls into your migration process, you ensure the safety and reliability of data during the transfer. This also helps you ensure that only authorized personnel have access to critical data, preventing unauthorized users from accessing sensitive information.
For SAP on Cloud:
Generally, we use security groups to filter traffic and only allow the required SAP standard ports to secure the SAP environment. We can either allow specific IP addresses, CIDRs, protocols, and port numbers when configuring the rules. These security groups are applied at the network level depending on the requirement of the application owners.
6. Estimate workload costs and perform right-sizing for VMs.
The sheer amount of data that needs to be migrated, as well as the need to maintain continuity of service during and after the migration process, makes it challenging for IT teams. To make sure you migrate successfully, you need to estimate how much data will need to be moved (by calculating the database size of the source system) and what type of VM will best suit the system to be migrated. Then determine which applications or services should run on which VM instances. This way, not only will you determine the right sizing, but also helps you maximize efficiency for your investments in the cloud.
For SAP on Cloud:
SAP Sizing involves determining the hardware requirement of the target system which includes memory, CPU power, disk space, I/O capacity, and network bandwidth. When performing sizing for SAP systems, you need to take into account whether it's a new (greenfield) implementation or you are looking into upgrading or migrating (brownfield) systems to extend new functionalities.
If you are to perform sizing for a new implementation, you can use the SAP Quick Sizer tool to easily translate business requirements into technical requirements by simply filling in an online questionnaire. When you are upgrading a system, you need to monitor and analyze the CPU/Memory utilization and database performance metrics based on the workload such as the number of concurrent users using the application at peak times, etc. For AS-IS Migration, the easiest way to do it is to check the RAM and CPU of the existing source system and deploy a VM with a similar configuration in your target cloud environment.
When migrating databases, you can use the same sizing tool or calculate SAPS (SAP Application Performance Standard) which is a hardware-independent measurement unit representing a throughput processing requirement.
7. Validate source system and document reference architecture.
Validation should reflect the sizing and architectural decisions should be properly documented. If you are unable to accurately validate your source system against the reference architecture, you may experience gaps in functionality or even worse—an inability to restore lost data due to mismatches between source and target systems. Once validation is complete, create detailed documentation for each component of your reference architecture so that future teams can quickly understand how everything works together.
For SAP on Cloud:
Validating the source SAP systems prior to migration can be done by executing SAP standard Tcodes. You can also install the target VM and SAP by downloading the correct media files (i.e. database, kernel, IGS, IGS helper, etc.) for the SAP installation, installing saptune, and gathering source portfolio metadata such as server names, IP addresses, OS, CPU, memory, IOPS (Input/Output per second), application name, database type and size, storage type and size, etc.
8. Adopt an agile mindset.
We recommend looking at cloud transformation with an agile mindset. To put it simply, start small and simple. There's no one-size-fits-all approach to cloud migration but having an agile mindset allows for more flexibility and enables you to move forward with more confidence as you optimize the efficiency of your migration efforts as you go.
9. Automate and orchestrate wherever possible.
Cloud migration is a complex and time-consuming process that can be disruptive to your business. To minimize disruptions, revisit your processes and see if you can make use of automation to eliminate manual intervention and minimize potential disruptions caused by human error.
Automation also allows you to reduce the amount of time spent on tasks that can be completed with minimal user input. Depending on the migration scenario at hand, you can leverage Terraform and/or Ansible to provision VMs, install and patch applications, perform OS configuration changes, and more.
For SAP on Cloud:
When automating SAP migrations, we consider the configuration requirements of the application environment. In IT-Conductor, we leveraged Terraform and Ansible fully customizable scripts to automate most, if not all, required steps in migrating your application to the target cloud environment. Depending on the complexities of your environment, we tailor our existing automation templates to suit your needs.
As a best practice, adopt the “well-architected framework” and “deployment templates” from the cloud vendors with tested and certified configurations per operating system, database, and infrastructure components (such as storage, network, load balancers, etc.) to support each SAP product being deployed.
However, it still takes hours to execute Terraform and Ansible jobs. From setting up a jump server, pulling scripts from the repository, running the jobs in the terminal, and waiting for them to complete. IT-Conductor has taken these pain points into consideration by weaving them all together using the platform's built-in process designer and building an end-to-end workflow using process definition.
10. Perform post-migration validation.
Immediately after migrating your systems and applications to the cloud, it’s important to validate
that everything is working as expected. This includes verifying if SAP applications are functional, checking for any compatibility issues, and ensuring the reliability of data.
For SAP on Cloud:
When validating SAP migrations, the first thing that you need to check is whether or not all objects from the source system have been migrated to the new SAP environment. For AS-IS migrations, we generally keep the SAP version the same. However, in some cases, DB versions and kernels may not be the same. What's important is whether the application, services, and integrations are working as expected. You can also check the Tcodes like SICK (check whether there are any errors in the installed system), SM21 (check system log), and ST22 (Check system dumps). These three T-Codes are independent of any version of SAP. If automation reports and checks are available from platforms such as IT-Conductor, it would accelerate and standardize these validation steps.
It's also important to validate if all database objects, sequences, functions, etc. have been transferred without a miss. Verify the row counts, spot-check column values, make sure transactional data are current, and check whether the historical data have been brought over from the source system.
11. Establish evergreen processes to regularly keep systems in check.
However, not all issues are expected to be captured in one or two tests. Especially with the varying number of users and workloads, application behavior tends to change over time. This is exactly why establishing evergreen processes (i.e. monthly or quarterly remediation, upgrades, file storage cleanup, etc.) regularly is important as it avoids potential pitfalls down the road.
12. Leverage a comprehensive APM tool to monitor newly migrated systems in the cloud.
Monitoring the availability and performance of resources in the cloud is important in ensuring that systems are healthy. But that's not the sole reason why you need to monitor your newly migrated systems. You also need to make sure that end-users are satisfied with their experience. This is made possible by measuring user experience metrics that can be quantified and translated into useful insights.
For instance, measuring page load times can be attributed to the HTTP requests and their response times. When several users complain about slowness, you can check the historical data about the captured HTTP requests. There can be an influx of users at specific time ranges. Compare that to the reported user complaints. Slowness is not always caused by a degradation in system performance. This is where having a comprehensive APM tool capable of letting you see your entire environment at a glance and allowing you to look more into the bits and pieces comes into play.