I appeared on a panel at an Experian QAS event recently which had some great questions at the end of the session.
One of the questions asked was “how can a data migration project ensure business involvement?”
I wanted to expand on this question because it is central to why so many data migrations fail. I also believe there are lots of different ways to skin this one so feel free to jump in on the comments below.
What do we mean by Data Migration Business Buy-in?
Let’s start at the beginning. The business owns the data migration.
Now, I accept this is contentious when most companies rely on IT teams or outsourced systems integrators to do the heavy-lifting. However, the reality is that the business cannot simply put their baby in the creche for 12 months and then pick it up at the end.
I’ve had many a discussion (to put it lightly) with senior managers who are frustrated, concerned or downright vitriolic at the outcome of “IT’s mismanaged migration of our data”.
In every one of those situations the business had not engaged enough on the project.
If you’re a business owner of a system or department that is heavily impacted by the migration then please don’t sit idly by, you will have to get some skin in the game.
Buy-in 1: Don’t release complete control of the migration
First, you’ll need to accept that even though the contract says the SI will do everything and lose their shirt if they fail, this ultimately serves you no purpose as a security blanket.
Why would you want to give away that much control?
It’s crazy so don’t do it. Instead, get involved with the planning and status meetings. Get on the communications channels. Have a direct report actively involved in the governance and management of the project. Have someone on your team signing off the data quality management activities.
Get some skin in the game!
Buy-in 2: Release your Domain Experts and Sharpest Minds
Next, you’re going to have to release some of your sharpest domain experts. I know you perhaps didn’t specify that in the contract but accept that if an IT team is going to create a great migration then they need quality people who understand the legacy environment intimately.
The good news is that they probably won’t be on the migration project full time but they will be required so don’t moan and panic about the impact on your own projects when this request comes in. If the migration comes in 6 months late because there was no expertise available then your present problems are going to look miniscule.
Buy-in 3: Business expertise and focus within the core project
You’re going to find bad data during your data migration. I 100% guarantee this based on past data migration impact assessments that I’ve carried out and I’ve never met a practitioner who voices the same opinion. It may range from light issues to absolute humdingers that cause the migration to screech to a halt but they will be there somewhere just waiting to bite you in the proverbials.
The business must be core to this review process because it requires their domain knowledge and ability to determine what data quality resolutions are required to make the new data work for the business in the target environment.
Your IT guys can do exciting stuff with data profiling and mappings but they can’t infer whether missing data will completely stuff up the way Jane in HR posts her employee payslips at the end of each month.
Buy-in 4: Support the investment of the right technologies and skills
If we ever have a few beers together I’ll eventually get onto my story of the global manufacturer who refused to hire a data migration leader on the project because they already had “a pretty good idea of what the plan will be”.
The industry is littered with stories and anecdotes of huge assumptions that are totally unfounded and are only proven to be worthless when that 5th attempt at data loading fails and people start dusting off their CV.
The business leadership has to ensure that whoever is delivering THEIR data migration is using the right technology and skills. You will face a huge challenge trying to perform a data migration with a mixed bag of developers and DBA’s with no prior experience but an insatiable desire for SQL and shell script.
If you’ve never attempted a data migration internally before ask for help and get some advice. If you choose to do nothing else at least get some input on the appropriate data quality technology because that is generally something every project ignores.
Buy-in 5: Don’t throw it all away – keep the data quality management capability
So your data migration is at an end. You either pat yourselves on the back for a job well done or spend 24 hours a day on Jobserve mulling over what went wrong.
It’s time to wind things down so the data quality and ETL software licenses are shut down. The documentation is stored away never to be seen again and everyone disbands to other projects.
Losing this valuable resource is a classic data migration mistake that can be easily avoided.
You’ve invested in all this time and energy to understand your data. You’ve measured it, improved it, monitored and protected it. The very reason it got in that state was because there was NO data quality or data governance in place. Why repeat this cycle on the new system?
Take a stand as the business owner of the new system.
Demand that everything the team learned over the last 12 months be transitioned into an ongoing data quality initiative.
Okay but how do we get data migration business buy-in?
The best answer to this I think came from Johny Morris in an earlier interview on Data Quality Pro:
“Right at the outset tell the business you are shutting their system down on a specific date. Tell them they are responsible for defining the criteria for shutdown (Johny calls it System Retirement Policies – nice title). Ask them when can they get involved.”
By pointing out that a system will be shut down you grab business attention. They sit up, collect their dropped jaw off the table and mumble something about future software releases and immovable deadlines.
If the business HAS to specify what the requirements will be to sign off the shutdown of a system then the accountability shifts 180 degrees. They have to understand what all this data migration activity means. Your role of course is to help and not just leave them high and dry. Given them a template for system shutdown criteria. Outline their roles and responsibilities. Pinpoint which staff will be required and what tests will satisfy them that yes, this new target system will do nicely thank you.
So there’s a few tips but what about you? How have you secured Business Buy-in on past data migrations? Please share your views below.