« Vlookup, Excel and social media. | Datamartist presented at Democamp Toronto »
Data migration- Part 1 Introduction to the data migration dilema
The world is a dynamic place. Businesses change. Companies merge, technologies shift and applications come and go.
Our data, however, is often less dynamic. All those sales records in the old sales system don’t morph into the format required in the shiny new ERP. The data has to be dragged kicking and screaming into the new format.
Thus, the art and science of data migration is one of the most challenging, and most important, of the information technology black arts. In the next few posts, I’m going to take a light hearted, but hopefully useful look at data migration.
So imagine you are in a company that, for whatever important, unavoidable, and “it was super clear at the time” reason is going to change its sales system. The new system is just so much better- as the VP of marketing points out:
“The new sales system will drive synergies and encompass our core strategy for value creation and customer focus.”
Oh good.
What are the possible strategies in regards to moving your data?
Abandon your data
Sure, just shut down the old server, send the hard drive to the recycler, turn on the new system empty, and wait by the phone for the next order.
“Hello, Acme lots of products, can I help you?”
“You’d like to place an order, ok, can I get your company name and address please.”
“Yes, I know you’ve got a customer number, but we don’t use those any more, they’re from the old system. We have a new one now.”
“You want product 23432- that’s an old code, let me try to find the new one, just a sec…”
Probably not going to work out so well.
Enter all your data by hand over the weekend.
Depending on the amount of data, you might actually be tempted to do this. Sit a bunch of people in front of a bunch of computers, give each of them a stack of reports from the old system, and show them how to enter the data into the new system. Buy them pizza. Look really stressed as 6am Monday morning approaches.
The “advantages” of this approach:
- Because the new system thinks that you aquired every one of your existing customers over a two day period your companys growth rate looks fantastic.
- You get written up in computer science journals as a case study on the error rate for manually keyed data. The researchers are particularly excited about the clearly defined ramp affect built in by the progressive sleep deprivation of the data entry clerks.
- You get lots of practice calculating customer abandonment metrics as over the next six months data errors cause undelivered invoices, mis-routed orders and incorrect product configurations. You get excellent data on what makes customers most angry, and drives them to switch to your competitors most quickly.
- Even though the new sales system doesn’t work out so well, the reduction in transactions makes it possible to save lots of money by reducing the number of servers and the amount of storage needed in the data center.
Or, you could launch a data migration project
Yep. Probably what you should do. But how?
Seriously, what are some things to consider in a data migration project?
Over the next few posts, I’m going to continue on the theme of a sales system migration, and talk about strategies that can help get you through your project, and the kinds of “Gotchas” that can spring up. Every data migration project is different, but hopefully I’ll shed some light on the process, and share some of the experience I’ve had.
For me, the number one thing to think about in a data migration project is the impact on your customers.
Remember those customer people? The ones that give us money and expect something good in return? Turns out they’re the cornerstone of your business.
Minimize the impact on your customers
Now, I’m not saying that you shouldn’t consider other stakeholders too, and there is always political and financial constraints to any large project, but if it comes down to a choice between making life difficult for someone inside your company, vs a customer- well, someone has to take it for the team, and the customer isn’t the right choice.
A badly executed migration project can cause enough issues for customers to push those that were wavering to the competition. A really badly executed one can push loyal customers away.
Depending on how cut throat your industry is, it could cost you significant marketshare, maybe even end up being the start of the end.
On the other hand, a well executed migration to a system that not only cuts your costs but provides real value to the customer could be a key part of your competitive advantage.
Next post: A data migration project is never just a data migration project- it’s a data quality project too.
« Vlookup, Excel and social media. | Datamartist presented at Democamp Toronto »