The following steps are performed when doing a migration. Use Agile teams of SMEs to do POCs to determine the right approach. HLD signed off by the client, over time, given hands-on this can lead to a migration E2E.
1) Prepare the application and database data, for transfer to the target environment. This usually involves a fully compressed backup of files/folders requiring migration, including making a fully copy of the production database (Virtual Machine copies). The target platform will typically have a ‘Development and Pre-Production Environment’ and a ‘Production’ environment. They should be the same (same AMIs, instances, OSes, environments), but separated and secured by role and access keys. Once Dev-Pre-Prod is tested and passed simply copy the same machine images and stack into Production.
2) Copy data and files to the target server. To do this properly, setup the application at the destination server environment as it existed at the source server environment. Use the same folder paths (to avoid potential issues with hard-coded paths), as well as the same database names and usernames. You can use database migration tools or native tools provided by the Cloud platform vendors (IaaS or PaaS), including for example DMS by AWS.
3) Restore files on the target server. Once the files and databases are copied to the destination server, restore them to the appropriate home directory folders and restore the database to the respective database server.
4) Configuration. The next step will be reconfiguring the application to run in the new environment. For this step, identify any/all application configuration related files. If file paths or database login credentials have changed, update those paths and connection strings in the application at the destination server environment.
5) Specific server settings. This will depend on the type, version, build and complexity of the application, and it may require specific server settings (web, database, file system permissions, etc.) and dependencies (libraries, services), which must be configured in accordance with the requirements of the application.
To help mitigate server settings it is helpful to have a thorough deployment document which details all the configuration requirements. If this is not available, then using an Agile or ‘fast-fail’ process will be necessary to do trial and error testing.
6) Web application specifics. If the migration is moving to a platform using a load balancer, clone web-heads to the additional web servers or repeat the process for the web/application files to all of the additional web-heads in rotation. Set up file replication across the web-heads (rsync, lsync, glusterfs, etc.). If the web application is being load balanced for the first time, it needs to be load balancer-ready.
7) Multi-DB servers. If we are using multiple database servers, setup a master-master or master-slave configuration. Depending on the destination server architecture, this process can become quite complex and could involve some time and expert DBA-DB SME work.
8) Testing. Typically done in Dev-Pre-Production and confirmed before copying the same environments and stacks to Production. Comprehensive testing is needed prior to going live. In Dev-Pre-Prod configure the destination server environment, assign an IP to the application, restore the database(s) and reconfigure the application. Automated script testing along with manual testing is necessary. Once tested we would repeat the process in Production. Many products both open source and paid, exist to help test the system in the cloud.
9) Go live. A quick checklist before going live and cutting over to the new production system:
–Lower TTL Values
At least 48 hours before the go-live event is scheduled, lower the Time To Live (TTL) values on any domains that are going to need to be pointed to the new server environment during the go-live event. In most cases you can lower these values to just 5 minutes (360 seconds), although some registrars require higher values. This will reduce the time of the DNS propagation.
–Downtime
There are two options to consider depending on the impact a brief period of site unavailability may have on your business:
- a) If the application simply cannot be down (i.e. in a maintenance mode) even for a short period of time, your only option is setting up database replication and reverse proxy between servers. This can significantly increase the complexity, cost and project lifecycle for any migration.
- b) If a temporary ‘maintenance mode’ is acceptable, this is a pretty simple step-by-step process:
- place the application into a maintenance mode
- synchronize the data
- switch the DNS
-Database and File Synchronization
Take a final copy of the database from the source server environment and restore it at the destination server environment for any recent changes. Or, use a migration tool (such as DMS, Oracle Data Guard etc) which replicates the changes in the DB in real time, from the source to the destination.
Search the source server environment for any/all files (usually images or documents) that have been added during the initial migration, testing and troubleshooting, and restore them, or make sure they are present, in the destination server environment. We can do this in Dev-Pre-Prod before copying over to Production.
At the conclusion of the database and file synchronization, perform a quick test of the application at the destination server environment.
-DNS Changes
Once all files/databases have been synchronized Login to registrar or DNS service provider and change the A record(s) to point to the new server IP(s). Since the TTL value is 48 hours the propagation (time it takes for the DNS services around the world to reflect your IP change) should be quite fast, usually 2-4 hours or even less.
10) Migration support
It typically takes 10 business days for the new platform to be declared ‘stable’. At this time, you can consider future improvements to the stable system and reduce direct support headcount. Ideally the ops team are the same team that did the migration and who know the application. If they are not, you need to budget and plan for a handover before cut-over and have the migration team on hand and ready to help for at least a week.
The above are the main details in migrating database and applications to the Cloud.
Note file servers, AD, and other dependencies were not included in the above steps. Usually there are MX, DFS, NFS and other related dependencies for the end-user. These will require a separate discovery by appropriate SMEs and detailed documentation. For example, you cannot migrate a File Server to the cloud if the documents contain security risks, clear text passwords, or domain information. AD is a complex environment and the AD database hierarchy needs thorough documentation and understanding or users may be prevented from accessing applications and data if domains and endpoints are not properly assessed and configured.
==END