The Data Migration Journey: Why and How to Migrate
As businesses look to grow existing IT assets, they may ﬁnd they’re limited by decisions made 5-10 years earlier. This is an issue commonly associated with legacy applications. These applications inhibit future growth. This has led to a number of organisations migrating applications to the cloud, the obvious beneﬁts of cloud migration being elasticity and scalability. Elasticity is the ability to grow or shrink infrastructure resources dynamically as needed to adapt to workload changes in an autonomic manner, maximizing the use of resources. Scalability on the other hand, includes the ability to increase workload size within existing infrastructure (hardware, software, etc.) without impacting performance.
With many businesses looking to migrate to the cloud, the most pressing concern is often around data. What happens to the data I just spent 5 years collecting? This data is generally business critical so it can’t be abandoned. The answer; data migration.
Getting your data from point A to point B should be easy right? Control C, Control V. Unfortunately it’s not that easy, and unless you want to manually input every piece of data collected over the past X number of years, a data migration is your best option.
There are three key steps to a data migration. 1) Extract data. 2) Transform data. 3) Load data. Doesn’t sound too hard. So, why are only 60% of data migrations completed on time? Firstly, the data migration may be handled by a business’ internal IT department. With businesses already stretching their IT resources it’s difﬁcult to add a full scale data migration to the mix. Other tasks are prioritised and suddenly the data migration is two months overdue. Secondly, there are risks around outsourcing migration that need to be considered. If the migration agency doesn’t conduct a detailed analysis of the client’s infrastructure at the beginning of the process then issues may arise down the track. With a strong understanding of the architecture, the migration agency can anticipate potential issues.
Once the new architecture has been tested and approved, it’s time to migrate your data. Without getting into the speciﬁcs, you’ll need to use a migration script to move the data source to your new target (the new database). We use SQL (Structured Query Language) to access and manipulate databases. If you’re interested in how migration scripts work, you can head here.
Next, you want to conﬁrm the migration complies with the initial requirements and that the data moved is available for business use. At this point, the data in your old system should have been moved in an appropriate format to your new cloud server. It should also redirect any new data to the cloud application. To conﬁrm this, audit trails and logs can be used to ensure that all data has been correctly migrated.
The most important consideration when conducting a data migration is security. You need your data to remain secure while it’s moved from the old legacy application to the new cloud application. Data migration is only a portion of the work required during a legacy system migration. Download our whitepaper to view the entire process.