Reduce cost inflation and cybersecurity anxieties when planning and executing migration to cloud computing with the following tips …
Taking into account the recent technological strides that have been made by various cloud platforms, organizations embarking on a typical cloud migration project need to consider a list of strategies and best practices to smoothen the journey.
Thorough planning is the first step. The planning phase should involve analyzing migration costs in tune with the deployment options suitability with different cloud providers. In the phase, licensing issues for the migration need to be addressed; the right teams and responsibilities have to be identified and trained in advance; the escalation hierarchy needs to be set up. Plan on agile sprints, whereby business, technical and testing objectives, and tasks for each sprint cycle, have to be established.
Also, a test plan should be drafted to test the landing or destination network/cloud account(s) for each sprint so nothing is lost during the migration due to security holes created by misconfigurations. Assuming X is the estimated time allocated for migration, be prepared to spend at least quadruple the X amount of time just for planning.
Early in the planning, choose multi-cloud and hybrid-cloud from the outset if possible, to avoid vendor lock-ins and thus enhance future interoperability. This is also the time to leverage cost efficiencies of certain services/resources by specific cloud providers, consider the Edge locations available; plan for seamless integration with on-premises and other infrastructure resources needed — such as VPN, Bastion hosts, application firewalls, proxy servers and so on, and set out all post-migration procedures …
Implementing the plan
The next phase after painstaking planning involves laying out the migration details into appropriate documents and strategizing the migration:
- Prepare a questionnaire covering all aspects of the migration
- List out the application portfolio and infrastructure components needed for the migration
- Define requirements for the migration and match them with readiness assessments
- Establish the artifacts of the migration plan, activity tracking and sprints
- Maintain a to-do list of tasks for each sprint; inventories of the move; architecture; and topology diagrams
- Prepare config management dBs, project management documents and automated spreadsheets to plug-in alternate scenarios especially for Disaster Recovery during and post-move
- Start the actual migration small but attack the critical sub-components early on during the move. Fail early and fast. Apply this experience to improve preparation for downstream migration processes.
Next, identify all manual deployments that can be automated:
- Document each and every manual deployment (for both infrastructure and applications) of the last few years that get repeated in your organization
- Establish a deadline to automate them through CI/CD processes
- Migrate all manual deployments to automated deployments and try them out in the on-premises setup your organization is currently in. These steps will help in CI/CD processes from the get-go in the new cloud environment(s) after migration
Other considerations
Keep an eye on cloud-native deployments that can be fully utilized. Consider using cloud-native containerized deployments instead of static servers. Invariably this will result in less cost over the long run.
Leverage the cost conscious/just-in-time facet of cloud resources such as “reserved instances” and “on-the spot instances”. Try to design the migration around the “pay as you go” philosophy of cloud computing. Extend the migration design to implement auto-scaling, business continuity, multi-availability zone failover and multi-region DR scenarios as needed.
Also, small- and medium-sized enterprises can consider moving both apps and infrastructure in one-go:
- The cut-off for large server moves in one chunk vs cut-off for incremental small moves require comparatively less time and costs less when we compare idle times of people and hardware during the migration
- Moving large workloads (backed-up with considerable planning) will help cut down the cumulative and average downtimes of servers and migration testing duration
- For large enterprises, it is prudent to separate app and infra migrations unless thorough planning has been done prior to this critical decision.
Finally , during the migration, do not consider rapid modernizations, but emphasize thorough testing:
- Application modernizations are a no-go during the move but consider them post-migration, as considerable time could be spent and this can escalate costs due to scope-creeps.
- During the migration, lift, rehash and shift to the cloud. The rehash could be rehost, re-platform, re-architect/refactor (listed in increasing order of time and effort needed). Rehash is where most organizations go wrong. It should be done carefully with the infrastructure optimization, application usability and cloud cost savings in mind.
- Perform thorough Security, Compliance and QA testing for all use cases, after establishing server cut-offs for the sprints.
- To eliminate security loopholes the decommissioning team will delete unnecessary servers/snapshots, databases, ports, user accounts, privileges/permissions, instances, test data during each sprint.
Post migration strategies
After the migration, have the security readiness list, compliance assessments, shared responsibility model checks, data protection measures, ITSM integrations, SIEM, Monitoring tool deployments done immediately after commissioning.
Check whether large datasets were moved completely and securely. If needed, reassess and remove root user permissions/privileges used during the migration. Check if multifactor authentication and IAM roles have been implemented for all users.
Execute the post-migration operating model that was defined during planning phase, then proceed to implement all managed services.
