Follow these tips for a smooth Database Migration
Ah, the dreaded database import. The aspect of every CRM / database change we wish would just go away and leave us alone. Always necessary, often costly and generally just a giant headache.
Have you ever felt a bit powerless when going through an import process? The good news is there are a few things you can do during your next database import to make things go a bit smoother.
Be aware of the pitfalls of a fixed price for database migration.
I wanted this first point to be “Don’t set a fixed price on your data import”, but the idea of open-ended technology projects might be enough to cause some of you to have a bit of a panic attack.
On one hand, it’s completely reasonable to say, “That is way too risky. I am putting all my trust in this vendor to deal with me fairly and not over-charge, as I’m essentially writing them a blank check.”
On the other hand, I’d say you’re handing over the most important digital possession of your organization, your data. If you don’t trust the vendor already, you should be taking a step back and re-evaluating your vendor selection.
The problem is, a successful vendor-client relationship is a partnership where both the vendor and the client are working in a framework where their interests are aligned.
Data imports can be very tricky, as it can be very difficult to foresee all the different issues that might pop up during the import. And when you have a fixed cost on the project, it sets the stage for the alignment of interests to be thrown out of whack.
When there is a fixed price, that essentially puts a timer on the project. When you start, both you and the vendor’s goal is to get the data imported properly and cleanly. However, with a fixed price and after a certain number of hours, the vendors will find themselves in a situation where their goal changes from doing the job properly to finishing the project as quickly as possible. Since after a certain point, every additional hour on the project is costing them money.
This often results in cut-corners and mistakes that you don’t notice until much later down the road, by which time it’s far too late to do anything about it.
You need to be closely involved with the data import project.
This is pretty much a universal truth for any technology project, but it applies double for imports. Many failed projects can often be tracked back to a client who views the project as a task to be done solely by the vendor, while almost every technology project will require participation from the client to succeed.
This is especially critical with data imports, as they are unique in that they can appear to be correct on the surface but have problems and errors lurking beneath. These problems and errors won’t get discovered until months later if they are not scrutinized during the project. At that point, very little, if anything, can be done to fix the problem.
A good vendor should be soliciting your input regularly throughout an import. It is impossible for any vendor, no matter how good they are, to have the same domain knowledge of your database that you and your team will have. So they will need your expertise to confirm the way the import has been done and that any assumptions they have made are correct.
If they announce the import is complete without seeking your review of the data at any point, beware. That is a red flag and you’ll want to check the data as thoroughly as you’re able.
Always test before your final data import.
It’s never a good idea to plan one file import assuming everything will be completed successfully. In hundreds of data imports we’ve completed successfully, I can’t remember a single time in my career where everything was perfect on the first go and didn’t need additional adjustments and changes to get everything imported properly.
As a best practice, we like to import a small subset of the data to make sure the model we are using to import the data is correct. This works well, especially when working with a large database, because it’s quite quick to import a small subset, and you can test the model being used to ensure all the data is flowing into the new system properly. This makes it easier to fix problems and test those fixes.
Once the limited import is solid, then you can run the same process on the entire database and, you guessed it, test again. This method has proven successful for us time and time again.
Database migrations will always be a bit scary and stressful. I wish I had better news on that front, but if you implement these strategies, you will be able to exercise a bit more control over the import and make the stress a bit more manageable!
About the Author: David Saraiva is a partner at www.DonorEngine.com a true all-in-one software solution for non-profit organizations. Reclaim hundreds of hours of time and serve your donors better with Donor Engine. What would your organization do with an extra 50 hours a month? Find out with Donor Engine!
