The Data Migration Journey: Why and How to Migrate

As busi­nesses look to grow ex­ist­ing IT as­sets, they may find they’re lim­ited by de­ci­sions made 5-10 years ear­lier. This is an is­sue com­monly as­so­ci­ated with legacy ap­pli­ca­tions. These ap­pli­ca­tions in­hibit fu­ture growth. This has led to a num­ber of or­gan­i­sa­tions mi­grat­ing ap­pli­ca­tions to the cloud, the ob­vi­ous ben­e­fits of cloud mi­gra­tion be­ing elas­tic­ity and scal­a­bil­ity. Elasticity is the abil­ity to grow or shrink in­fra­struc­ture re­sources dy­nam­i­cally as needed to adapt to work­load changes in an au­to­nomic man­ner, max­i­miz­ing the use of re­sources. Scalability on the other hand, in­cludes the abil­ity to in­crease work­load size within ex­ist­ing in­fra­struc­ture (hardware, soft­ware, etc.) with­out im­pact­ing per­for­mance.

With many busi­nesses look­ing to mi­grate to the cloud, the most press­ing con­cern is of­ten around data. What hap­pens to the data I just spent 5 years col­lect­ing? This data is gen­er­ally busi­ness crit­i­cal so it can’t be aban­doned. The an­swer; data mi­gra­tion.

Getting your data from point A to point B should be easy right? Control C, Control V. Unfortunately it’s not that easy, and un­less you want to man­u­ally in­put every piece of data col­lected over the past X num­ber of years, a data mi­gra­tion is your best op­tion.

Migration Steps

There are three key steps to a data mi­gra­tion. 1) Extract data. 2) Transform data. 3) Load data. Doesn’t sound too hard. So, why are only 60% of data mi­gra­tions com­pleted on time? Firstly, the data mi­gra­tion may be han­dled by a busi­ness’ in­ter­nal IT de­part­ment. With busi­nesses al­ready stretch­ing their IT re­sources it’s dif­fi­cult to add a full scale data mi­gra­tion to the mix. Other tasks are pri­ori­tised and sud­denly the data mi­gra­tion is two months over­due. Secondly, there are risks around out­sourc­ing mi­gra­tion that need to be con­sid­ered. If the mi­gra­tion agency does­n’t con­duct a de­tailed analy­sis of the clien­t’s in­fra­struc­ture at the be­gin­ning of the process then is­sues may arise down the track. With a strong un­der­stand­ing of the ar­chi­tec­ture, the mi­gra­tion agency can an­tic­i­pate po­ten­tial is­sues.

Once the new ar­chi­tec­ture has been tested and ap­proved, it’s time to mi­grate your data. Without get­ting into the specifics, you’ll need to use a mi­gra­tion script to move the data source to your new tar­get (the new data­base). We use SQL (Structured Query Language) to ac­cess and ma­nip­u­late data­bases. If you’re in­ter­ested in how mi­gra­tion scripts work, you can head here.

Next, you want to con­firm the mi­gra­tion com­plies with the ini­tial re­quire­ments and that the data moved is avail­able for busi­ness use. At this point, the data in your old sys­tem should have been moved in an ap­pro­pri­ate for­mat to your new cloud server. It should also redi­rect any new data to the cloud ap­pli­ca­tion. To con­firm this, au­dit trails and logs can be used to en­sure that all data has been cor­rectly mi­grated.

Stay Secure

The most im­por­tant con­sid­er­a­tion when con­duct­ing a data mi­gra­tion is se­cu­rity. You need your data to re­main se­cure while it’s moved from the old legacy ap­pli­ca­tion to the new cloud ap­pli­ca­tion. Data mi­gra­tion is only a por­tion of the work re­quired dur­ing a legacy sys­tem mi­gra­tion. Download our whitepa­per to view the en­tire process.


Matt Francis

Brewer of beers, smoker of meats

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call