8 Tips for Becoming a Better Data Migration Client

It’s all too easy to blame your data migration solution provider when your project hits the rails but are you really doing everything on your side of the fence to ensure project success?

Use these tips as a starting point for determining what your company should be doing to ensure project success for all concerned with the implementation.

Several years ago, whilst working for a consulting group, I was approached by an existing major client who wished to have an external specialist migrate substantial volumes of highly complex data.

The challenges were varied:

• 20-30+ systems, some of which went back 15 years, client had no idea how many systems would be required

• No real data quality measures aside from finger in the air guesstimates

• Complex political “turf-wars” and lots of power plays

• Fixed deadline for completion due to regulatory timelines

• Requirement for a fixed price implementation

• Strong desire to offshore the development and slash costs across wherever possible

So, outwardly this may have looked like the dream project right? Big name client, multi-million pound contract, bonanza time! Sadly, no.

The client had lost touch with reality. Some simple calculations based on even optimistic time scales and resources revealed that it was physically impossible to migrate the volumes of data they were expecting, simply from a complexity perspective.

Even if your pockets are deep, do not assume that simply throwing huge amounts of cash at a problem will make it go away.

Be totally realistic about what can be achieved. A lot of consultancies will tell you what you want to hear because they have their goals to consider, not yours.

If you’re looking for external help with your data migration it pays to take the initiative in a number of areas, requirements management being the most critical.

I’ve seen too many projects kick off with only some vague notion of what measures will determine project success. You need to take the steer on the exact requirements your service provider must fulfil.

A classic mistake is to leave the issue of data quality floating precariously between both parties. Many system integrators will offer to measure and assess the data but cleansing and improvement will typically be additional items, the classic “data quality get-out clause”.

You as the client must take data quality by the scruff of the neck and measure it, define it, scope it and negotiate price on it accordingly. Get data quality at the forefront of your project strategy from day one and ensure it is fully measured and understood.

One of the biggest obstacles to success on any data migration project is the failure to have the right type of legacy or target skills available when required.

As a client this is firmly your responsibility. You need to ensure that Jeff, the 25 year vet who developed that crumbling CRM system from C and Informix back in 1995 will be on hand to decipher those 4GL function definitions that have never been documented.

The same applies to the target system. Many integrators will not be responsible for the new application environment but they will need specialist knowledge on how to load data into the API or back-end database. This is your job as client to provision this knowledge.

Most migration projects fail or overrun. With these statistics ringing in the clients ears there is little wonder why many contracts and project relationships are based around a punitive strategy.

“You will deliver this project or else” seems to be the way forward for many clients who are (rightly) nervous about the future success of the project.

The key here is to look at the project as a real collaboration. If you were entering into a business partnership you would focus on building a culture of sharing the victories, not regular beatings for missed opportunities.

• How can you structure the contract so that it is based around a reward strategy?

• How can you set up the team environment and culture so that there is less “them and us” and more “we’re in this together”.

This is related to Tip #3, but access to the staff on its own is no good if they are not motivated or incentivised to help. If they have been working with the source system for 15 years and their whole career is based around it, they may have no interest in assisting.

Worse still, they can be disruptive.

Advising them that they will be made redundant on completion of the migration can often be the worst thing to do. It is important to understand what will motivate them to help, whether they can be retrained on the new system, or even to become a data migration expert.

Don’t just leave it to your solution provider to build the migration process and deliver back some data for testing in a few months’ time.

You need to review each stage of their approach to the project: the data analysis; design; mappings; test plans; processing times; cleansing approach; auditing etc.

It must always be seen as a joint project involving business, IT and the migration provider. An expert provider of migration services will always insist on this, but it can sometimes be difficult to persuade clients!

Numerous issues and queries will get raised in the building of a migration process.

They must be addressed and answered quickly and accurately. If they are not, your supplier will have an excellent excuse for any delays.

The responsibility for establishing a status/progress reporting framework that reflects the client's views resides with the service provider. However (in the spirit of partnering and improving the likelihood of success), the client should ensure that the data migration reporting framework provides them with the status, progress and issue information that they need to maintain a valid and accurate perspective of the activities completed, underway and upcoming.

A bad reporting framework is one that is challenging to understand and provides little information.

A good reporting framework is one that enables the clear and early/asap identification of issues and improves the likelihood of mitigation actions. If the client has this information in a format and language that they understand – then they can (also) actively participate in the identification and resolution of issues.

As data migration can easily fall into the trap of being viewed as a technical activity without business consequence, the reporting framework is one method of ensuring the tie between data migration and the business benefit/impact is established. It can also help with client buy-in and ongoing engagement throughout the project.

Dylan Jones

Co-Founder/Contributor - Data Migration Pro
Principal/Coach - myDataBrand

Dylan is the former editor and co-founder of Data Migration Pro. A former Data Migration Consultant, he has 20+ years experience of helping organisations deliver complex data migration, data quality and other data-driven initiatives.

He is now the founder and principal at myDataBrand, a specialist coaching, training and advisory firm that helps specialist data management consultancies and software vendors attract more clients.