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

Validation & Testing (Managing the Risk)

A wise man once said:

That’s right - we’re back with another instalment in our series on the 12 mistakes threatening your retail ERP migration. Last week, we discussed how people have a dramatic impact on what can be traditionally deemed an “IT” project, and how you need to have an engaged, bought-in set of business SMEs who can drive you forward.

If you missed out, go check out part 2 here: READ NOW

Don’t worry, I’ll wait.

Today, we explore how retail businesses mismanage risk during the testing phase, and why idolising a 'zero-defect' migration is a surefire way to blow your budget.

Let’s get into it!

MISTAKE #7:

Chasing the mythical 100% defect-free migration

Ah, this is a doozy. You’ve spent time and effort in your data workshops, and your DM team has had weeks to develop their solution to create the load files. The data should breeze in with all that prep, right?

The Problem:

Yes, Star Wars reference… something something nerd something something stereotype.

But it has relevance. Thinking your data will breeze in, or expecting 100% data loads (especially prior to your Cutover loads, too), is genuinely a trap. If you chase 100% perfection across hundreds of thousands, if not millions, of records, you will overrun on time, blow the budget, and exhaust your team.

A Go-Live will never be entirely risk-free.

When you stand up a data migration team, whether internally or you bring in a partner, their purpose is to move the bulk of your data. Your challenge is:

• How do I move 40,000 Workers and millions of transactions into my new system?

Not:

• Why are the DM team not spending hours debugging the solution because Bob from Accounts Worker record failed to load successfully?

To put it plainly: your challenge is volume, not edge cases.

A DM solution cannot account for all edge cases, nor should it. You are wasting time, money and solution confidence by trying to force this way of working.

I’ve seen it before:

If your SMEs are making statements like this, there is no forward thinking happening, which ultimately, does not support your transformational vision.

Food for thought:

• Set realistic goals with your DM Partner - A good partner (cough 👋🙂) will advise you based on their experience what level of data is necessary for each cycle. Most importantly, ensure it is set in stone in the DM Strategy, so all parties are on the same page

  
  

• Manual entry - The shock! The audacity! But, in all seriousness, most of the time when you have a handful of records that have dropped out, it’ll be faster and cheaper to have your SMEs enter them into the system manually, rather than getting your DM partner to edit the entire transformation to resolve <1% of issues. Not only that, you are de-risking the bulk load by not introducing untested code that could cause regressions leading to further defects.

  
  

• Your earlier test cycles should be about identifying the issues and resolving them. This works because you have further cycles to test and build solution confidence. When you’re in Cutover, you are beyond that. At this point, everyone needs to roll up their sleeves and do everything they can to get your system live in the most efficient way possible.

  
  

• You don’t need every single record to perform testing - I can guarantee there’s someone who’s reading this that’s holding their finger up in the air, exclaiming: “ACTUALLY, I DO BECAU…” - let me stop you there, chief. I get it, you might miss the edge-case that affects 1 record. What we need to remember is this:

  
  

• Validation is where truth meets tolerance.

As I said earlier, no go-live is risk-free. You do not have the time nor the budget to make everything perfect. “Correct” will be more of a sliding-scale based on your defined tolerance, rather than a binary true / false.

MISTAKE #8:

Checking everything equally instead of what matters

This is actually very pertinent to the above point, but I felt it was a key issue that warranted its own limelight.

The problem:

It’s easy to think it’s the end of the world if there’s an issue in your data loaded into your new system. With that, it may be tempting to equally scrutinise all data objects and all data columns.

That is incredibly taxing, and not a task that produces equal valued outputs compared to effort input.

Each data object has its own criticality. Having your employees correctly paid is much more critical than fully qualifying their learning completions.

If you miss your go-live because you’re holding everything back due to the detailed validation / reconciliation you’re doing on your Workers’ “About Me” bios, that’s going to be a hard discussion with your board.

Food for thought:

• Understand your ‘critical path’ - What are the key data objects that need to be in your new system to support critical business operations from day 0? What data makes the system actually function? If you know this, you know what must be prioritised - your functional data. Your non-functional / informational data — whilst important — is then not a blocker to your go-live, and can exist lower on the priority scale. This will help narrow focus and understand where time is best spent.

  
  

• Lean on your partners - You don’t have to do this alone. Your Systems Integrator and DM partner can support the planning of these activities and priority categorisation.

MISTAKE #9:

Delaying business reconciliation until the end

This one makes me shudder. If there’s just one thing you take away from this post, it’s this point.

It happens much more often than you would think.

It also links in with a comment from my colleague, Danny (you’d think he’s paying me to sponsor him at this rate, wouldn’t you?):

The problem:

Waiting until Trial Cutover, or even the User Acceptance Testing (UAT) phase to engage the business in reconciliation is a recipe for disaster. If you wait until the 11th hour to realise the E-com product catalogue didn't migrate correctly, you are putting direct sales revenue at immediate risk and guaranteeing a delayed Go-Live.

You should be executing at least 4 DM cycles across your project - if your SMEs are not reconciling data from the first formal testing phase, then your entire project is burying its head in the sand, saving issues until nearer to go-live, and jeopardising the success of your digital transformation.

If you leave business reconciliation until the end, there will not be enough time to rectify issues without delaying go-live. We have seen this on numerous projects where it doesn’t get prioritised (usually budget or resource constraints), only for it to be picked up near the end, with the project then going through an existential crisis as it doesn’t know how to tackle the hundreds of issues generated that *really* should have been captured and fixed earlier. Project timelines were extended every time, without fail.

Food for thought:

• Technical Reconciliation doesn’t cut it / you know your data - it may be easy to think that your DM team should verify their work. They will - but this is just one level of checking. The DM team will verify volumetrically, to ensure any dropouts across the DM lifecycle are caught. But, as we’ve discussed in previous blog posts - your SMEs know your data best. They are best positioned to verify the accuracy of the migration, and function as an independent verification source that has no insider knowledge of how the DM solution was technically constructed.

  
  

• Look for accelerators - it can be daunting thinking of how to reconcile data from scratch, but starting early allows you to build and evolve that process over time, to the point that when your final cutover cycle comes along, you have a slick process and everyone knows what they’re doing. Even better - realise that you are not treading new ground, this is something that everyone in your situation needs to undertake. Look for tooling, frameworks or methodologies that help get you to a structured reconciliation process faster.

  
  

• Drop us a line to learn more about our reconciliation offerings HERE

  
  

• You can use external resource - It might seem contrary to my first food for thought point, and I get that. Ideally, your SMEs are fully involved in the process and drive it forwards. Sometimes, though, capacity can be a problem and you can’t fully commit. In that case, there are experienced reconciliation consultants out there who can come in and support with the process building and initial question screening, allowing your SMEs to focus on validating statements or tough questions, rather than coordinating the entire process. The main thing is ensuring reconciliation is taken seriously and adopted early.

In closing, I wanted to end on this quote:

What, were you expecting something insightful, or inspirational?

Well, you’ll just have to wait until next week for the final instalment, where we will dive into the technical engine room. We’ll cover the architectural flaws and process mistakes that break trust in a migration solution.

Article by:

Chris Davis

Follow me on LinkedIn