In this article we provide a reality-check on the migration process and the areas where companies can quickly get into trouble. We will identify best practices and how to plan for your migration. As always, the devil is in the detail and starting with smaller workloads / wins can help achieve your goals while at the same time minimizing risk.
Why Migrate to Cloud
Cloud has now been tried and tested for several years – it no longer must prove itself, as more and more corporations from big Corporations to SMB’s migrate their workloads.
Moving from on-premises will change the way your company delivers its IT services, improve staff productivity and reduce your costs. It will also provide a platform to quickly react to changing business conditions for example launching new products or moving to remote working / boosting your on-line offerings.
Pitfall 1 – Not getting Buy-In from Executive Team / Senior Staff
Change is never easy at the best of times – there are always team members who don’t want to change for a myriad of reasons.
Always ensure you have the support and buy-in from leadership for your work-load migration. Failure to secure this usually results in delayed delivery dates, results that don’t live up to your expectations or even project rollbacks.
Best Practice Recommendation: Support from leadership must be in place and must be proactive and visible to all staff from day one of the migration project.
Pitfall 2 – Identifying the wrong workload for your first Migration
Many migration plans can be over-ambitious, over-complicated and take a long time to complete – this approach usually falls at the first hurdle. The key here is to be realistic and think small, quick wins that show tangible results.
Categorize your workloads as:
- Simple to move
- Medium or hard to move
- Complex or last to move. (Hybrid IT)
A lift and shift strategy for easier workloads that migrate faster will build your confidence and the business case to your leadership. You will also learn on this journey any sticking points that will be useful for the more complex migrations as your cloud journey progresses.
In some cases, it may be easier for certain applications to remain on-premise – don’t assume that everything must be migrated to the cloud.
Best Practice Recommendation: Identify smaller, easier projects for quick tangible wins – these will support your business case to leadership for more complex migrations and assist in transitioning you team to get comfortable with cloud environments.
Pitfall 3 – Failing to prepare for the Migration Process
Every migration is different however there are standardized migration processes which incorporate lessons learned from millions of migrations that Cloud Service Providers have seen. Review the following as part of you overall plan:
- Readiness to operate in the Cloud – assess your on-premise resources and Cloud cost projections for your workload. Identify any strengths and weaknesses and mitigate / action any gaps.
- Detailed Migration Plan – how you will build your base-line environment and identify your Migration Pattern and what Migration Tools will be used.
- Migrate and ongoing operations – the application design, migrate and validate stage. Identify timings for migrations, trouble hooting issues. Incorporate DevOps practices, Automation of Infrastructure and robust Cloud Architecture.
Best Practice Recommendation: Complete a modern CSP Migration Plan. Independent research confirms that Enterprises that follow CSP migration procedures are more satisfied with cloud services and cost savings than ones that have no comprehensive plan or adopt old or outdated migration approaches.
Pitfall 4 – Moving the data was a big challenge and there was more down-time than expected during the Migration.
Moving Data
Let’s be realistic about Data Migration in this section – yes there will always be surprises, but a good review of the data itself is always essential for a relatively smooth experience. Make sure you consider the following:
- Don’t just look at quantity of data look at structure – e.g. number of tables, columns, indexes and stored procedures.
- Outbound data migration will be dependent on internet bandwidth. This requirement should be carefully estimated, and a contingency added. Getting it wrong can cause delays in transaction processing time and run up the costs significantly.
- Bear in mind the time of day your migration is running – better off peak than during a busy work- day.
- Are other jobs running on the source system? – review their timings and if they will impact your migration.
A careful and detailed review of exactly what you are migrating will then assist you with choosing the migration tool e.g. AWS DMS. In cases where the data sets are simply too large to be moved over the internet you can consider portable systems such as AWS Snowball.
Minimising down-time during Migration
A careful, continuously replication of data can provide a seamless switchover between source and target. With this approach you must take additional care to make sure everything has been replicated prior to the switch. This also comes at a price so make sure you have budgeted for this approach.
Sometimes large data sets are simply not suitable for migration via internet and will need to be physically moved – again products such as AWS Snowball.
A final word of caution here – we have seen many instances where the client is so relieved that the migration has worked that they seem to forget it’s a Production system. Strong security permissions and authorizations may not in place on the target before starting – so always test your target system in terms of access and data residency before migration.
Best Practice Recommendation: Analyze your data very carefully prior to the Migration so you can pick the correct Migration Tools.
Pitfall 5– Security breaches during migration
Many migrations result in security breaches – some minor and others serious in nature. Here are a few of the scenarios we have seen play out:
- Be careful on how you store your Encryption Keys
- If Data is encrypted on your source – then make sure you have provisioned the same for your Target.
- Physical transfer of data should be fully secure and discussed in depth with your CSP.
- Your new system will require security checks such as Port Scans, Vulnerability Checks, Penetration Tests and Security reviews.
Best Practice Recommendation: Treat your new system as your production system prior to the Migration. Apply security checks – Your system should be Production ready with DevOps access.
Pitfall 6– DevOps/ Engineers can’t handle the new environment.
Its essential to cover off who will manage the new environment in your Migration Plan as well as identifying skills shortages. An infrastructure operated by inexperienced / un-trained staff can lead to exaggerated cloud costs, potential security incursions and unworkable systems.
Consider training, working with Cloud Partners, recruitment of experienced staff or an MSP provider who can typically operate an Infrastructure on a low cost basis while allowing your DevOps to focus on applications / other IT areas.
Best Practice Recommendation: Identify who will operate the Infrastructure as part of your Migration Plan and address any skills / resourcing gaps.
Pitfall 7– Forgetting to decommission old services after migration
This happens more often than you think – with the initial euphoria of the cloud migration and getting used to the new system the older service is discarded and forgotten. That is until of course you receive a new invoice or forget about some form of auto-renewal of an existing contract related to your old infrastructure / services.
Best Practice Recommendation: You may want to run the old system in parallel for a while, but decommissioning should be part of your Migration Plan. Existing contracts and costs should be identified in terms of end-dates, penalties.