Retail leaders: Fix 12 data migration mistakes before it’s too late (Part 1)

Part 1: Strategy & Preparation (Getting your house in order)

As retail businesses move to upgrade their key systems like their Entity Resource Planning, or Warehouse Management systems to tackle crucial business goals — such as digital transformation, or staying ahead of the curve — there’s often a considerable roadblock in their way that doesn’t get thought about until too late.

Their Legacy Data.

If you’ve been a part of an organisation that has undergone a significant system upgrade, you’ll be familiar with Data Migration. Apologies to anyone for whom this brings up deeply scarring, repressed memories.

For the uninitiated: Data Migration is where you bang your head against a wall for twelve months, extend the project for a further six, and spend sleepless nights worrying why you have such a low acceptance rate in UAT.

Of course, I jest…

Data Migration (DM) is the activity by which the lifeblood of your business (data) is transferred from one location to another. It takes many forms, but we are specifically discussing Enterprise Application DM here. We’ll touch on this a little more in Part 2, but a key issue is assuming that DM is a purely a technical task. There are technical elements to it, but it’s very much a human driven process. After all, who should determine what business data is migrated and the success of said activity - your IT team and consultants who support the systems, or business functions that create and manage the data on a daily basis?

If you’re unsure, tune into Part 2 for more on this subject.

At binary10, decades of data migration expertise have taught us a hard truth: DM projects rarely achieve perfect outcomes. Source data is messy, business rules evolve mid-cycle, and target systems behave different to expectations. If you aim for perfection, you’ll stall, or fail. But that doesn’t mean you can’t learn from the tribulations of others, and set yourself on a better path to success for your own DM project.

Over the next four weeks, we are breaking down the 12 most common data migration mistakes retail businesses make. We start today with Strategy & Preparation.

MISTAKE #1:

Enforcing arbitrary deadlines without real-world justification

We start with a fantastic point highlighted by my esteemed colleague (let’s not stroke his ego too much, mind):

The problem:

Retail has some clear trading periods that we must be aware of when understanding the logistics of migrating and cutting over to a new system. The chaos and pressure of trying to migrate and go live over a Christmas trading period is unlikely to be an experience anyone will want to sign-up for. Unfortunately, you won’t have a team of Santas working for you and alas, there are only 24 hours in a day (plus, Jane from payroll really could do with seeing her son at some point this week, even if just to remind him she’s still alive).

Jokes aside, committing to a timeline that either a) has no basis in the reality of the work ahead of you, or b) coincides with crucial business periods (such as Christmas, Black Friday, Valentine’s, etc.) will put an immense, unnecessary strain on your delivery team that will result in:

• Mistakes

• Delays

• Key resource burnout

None of which are ideal, and will ultimately cost money to rectify.

Food for thought:

• Arm yourself with information - what are your key business periods, and what does system downtime mean to your operations?

• Understand when your current system’s licence expires - this will give you some windows of opportunity, which you can measure level of risk against your known key business periods

• Whilst it is efficient: you do not need to go live with every module on day one in your new system. Consider what is day one critical, and work from there. You may find you can go live earlier with a reduced scope, and bring additional modules online once you’re stabilised.

• Consult with professionals: this is one of those times when bringing people in to help you is a fantastic idea. You’re already likely bringing in a specialist to support setting up your new system - don’t forget the data specialists, too.

MISTAKE #2:

Skipping the “get-ahead” preparation

So, you’re sold. Oracle Fusion is your Messiah, and Dynamics365 SCM is the second coming of Jesus. You’re on the precipice of a digital transformation programme that will massively improve the efficiency and capability of your business.

But, how are you using the time prior to your programme partners onboarding?

The problem:

If you’re waiting until your data partner and SI are onboarded, you’re losing out on this magic time to warm up your internal team and build an understanding of the challenge ahead of you with your legacy data.

You want your partners to be working towards a successful outcome for you from day one. Don’t let yourself be the broken link in the chain that immediately throws your programme off plan.

Food for thought:

• Create a formal data issues log - document your known data anomalies, structural inconsistencies, and major issues in the current legacy system. This greatly supports your partners’ discovery phases and arms you with the knowledge of what data cleansing activities you’ll need to carry out.

• Know your Data Owners - make sure each functional data area has a designated “owner” within your business who is empowered to make design decisions, and has the knowledge to back said decisions with confidence. Lack of ownership usually leads to unfocused sessions, hesitation, dead-end approvals, which all cost you time, and money.

• Identify your shadow IT / spreadsheet driven processes - these “magic” off-system tools and files are rarely discussed in the initial scope, but instead come up later in the programme, triggering costly change requests and delays against the timeline. Get an understanding upfront of what off-system processes need to feed into the migration, so they can be factored into the discovery and design phases.

  
  

• Cheap plug alert: Looking for support with assessing your Data Migration readiness, and understanding what other get-ahead activities you can undertake for the best start to your programme?

  Book a consultation here with a Data Expert here at binary10 and tell us a little about your project.

• Seriously, speak to someone who has been through it before. Whether it’s binary10, or someone you’re already connected with, you don’t need to re-invent the wheel here.

MISTAKE #3:

Expecting the migration to magically cleanse your data

Steve chips in with a great point here:

The problem:

You’ve collected masses of data over the years in your systems. This data will be of varying quality, depending on who entered it. There will be many touchpoints - customer self-service, store clerks rushing data entry at POS, employees managing their own information, often in freetext fields that offer zero validation checks… the list goes on.

You don’t want to bring poor quality data and years of debt over into your new system. You want that to be clean, lean and functional.

But what’s often forgotten is that the Data Migration process cannot wipe clean years of data-related sins, and that the expectation that it would do this, will lead to the overcomplication of transformation routines, that reduce your trust in the process (by introducing extra complexity), and increase the risk of failure.

Food for thought:

• Using your formal data issue logs from the *Food for thought* mentioned under mistake #2, take ownership over your data cleansing requirements to simplify the transformation process. Making one-off changes to data in the source system allows you to control how that data has been manipulated, and reduces the scope of affected records - remember, if you’re changing it in the transformation layer, that rule is then being checked against every record in that data object. No matter what, this increases your risk profile.

  
  

• Implement automated Data Quality checking - don’t have your SMEs manually combing your data for issues, automate this process with the appropriate tooling and have your SMEs validate the output instead. This will save your SMEs time, and sanity.

  
  

• binary10 has a Data Quality Tool that can be set up to identify and monitor data issues for your source system data. Book a consultation here with us to understand how it can help reduce manual effort in this area.

  
  

• Not all data is equal - no doubt that along the way, you’ll notice there are some data issues in lower priority areas of your legacy system. Whilst your focus will be on delivering clean, usable data into your new system, remember that you only have finite time, resource and budget to complete this data migration activity. Make sure your teams spend their focus in areas that drive business outcomes - such as order fulfilment and customer communication.

  
  

• Good enough, is good enough - this is an overarching theme but relevant to call out here, too. Define what “good enough” looks like for data quality against your data sets, and work towards that. Perfectionism kills progress.

BONUS MISTAKE:

Not subscribing to binary10

“Another plug? You must be shameless, Chris” I hear you say.

Well, yes, I am, thank you for noticing.

But if you’re looking for insightful data related content to help you put your best foot forward, why wouldn’t you want to subscribe?

Oh, just to remind you, this’ll be a four-part series where we’ll delve into further mistakes and provide some helpful advice and tips on how to mitigate these for your programme.

Join us next week for Part 2, where we’ll explore the critical people and governance mistakes that can stall a retail data migration in is tracks.

Article by:

Chris Davis

Follow me on LinkedIn