Issue 3: DM = Data Migration or Diabolical Mess?

removal_van_stuck

Welcome to the Orpheus Inversion series.  In the third of our series we examine five steps to fail spectacularly in your Data Migration project . . .

So, we’ve bought our shiny new system and are looking forward to reaping all those benefits.  But wait, what about all the data in the old system?  We need that data to run our business – so we’ll need to “copy and paste” it over won’t we . . . How hard can it be?

 

Step 1:  Know what you’re migrating?

  • No need to understand and select data to migrate from the outset; just “migrate
    everything, ok? “

 

Step 2: Planning and Scheduling

  • Don’t start until you’re some way through the project.  That way you’ll be clearer on how to approach migration.
  • If it’s too much effort, or your running out of time then just reduce the data set – but remember step 1!

 

Step 3: Only get expertise if you get in trouble

  • Data migration issues are business issues — but hey, IT has the expertise and the authority to resolve business ambiguities, trade-offs and uncertainties – don’t they?  If in doubt, assign a default!
  • If we need more hands one of our vendors should be able to help our staff.  And if they’ve done it before they should be able to “pick up the pieces” quick smart.

allourcustomers

Step 4: Project methodology – what methodology?

  • All DM projects are the same, so we’re pretty sure any of the contemporary project methods will work for us.  A couple of streams are agile, but the DM PM likes waterfall – so we should combine them and do a little bit of Waterfall to start; and finish with Agile.  With all due respect to Elmer Fudd, that’ll be a “weally Wagile” project!!

P.S. we did try for combining 3 – but  “WaPrile” just doesn’t sound as good!  I guess that just proves the old adage that, “two’s company and three’s a crowd!”

 

Step 5: Testing & QA, other stuff. . .

  • Testing.  If there is too much to test by hand then just build a tool to test the data migration.  We’ll need developers for that.  We better test the tool too.  We need testers for that . . . we’ve found a defect, is it the tool or the data?
  • Clean-up.  The data in the old system must be rubbish that’s why we’re migrating.  Let’s find as many issues with the old dataset as possible, clean it all up to ruin our baseline (and downstream apps), map it to our new format and then migrate it.  I think we’re going to need a few more people!
  • Reconciliation.  Record counts should do.  Next.
  • Practice makes perfect.  No need to practice too many times – that’s time consuming and expensive.  She’ll be alright on the night.

 

At Orpheus we know that the 2 DM’s – Data Migration & Document Management – are the most common reasons that projects run over time and budget.  Don’t let your project be impacted by what is often coined as “ancillary functions.”

allthedata

Give us a call and let us help you to do IT right.