In a perfect world, IT could push a button and move an enterprise's data from one location to another.

But of course this is not a perfect world, and the same complexity that makes databases the heart of an enterprise's operation makes it more difficult to move without careful planning — and more dangerous to mess up.

"The more time and effort you put into understanding the overall footprint of the system that you want to migrate the easier migration will be," Jason Hall, vice president of client services at SentryOne, told CIO Dive in an interview. 

Here are four common mistakes made in database migrations —​ and how to avoid them: 

1. Don't know what's being moved, or how much

Migrating a database is about moving data and everything that's hooked into that database too. To make the process smoother, enterprises should know what they're moving —​ all of it. 

"This is something that's a classic problem in technology shops. We don't do a great job of documenting what we have," said Hall. Documentation problems include data but also the performance footprint, architecture and all components and satellite processes that surround the system.

Enterprises should audit their software prior to a migration, Hall said. This helps in the migration and determining the right size cloud to move to. It also requires a mental shift because organizations tend to buy more compute than they need.

"We need to change our mindset and understand what our workload uses on average, and build in elasticity," Hall said. That includes understanding any seasonality of workload when compute grows or shrinks too. 

During this advance planning, organizations should also be able to identify which vendors don't have "cloud-friendly licensing models," Colin Dawes, chief solution architect at Syntax, a managed cloud provider, told CIO Dive. "Look to see if there's a penalty for running in the cloud, or not running in a very specific cloud." 

2. Don't move the right way

Just like an enterprise needs the right cloud to move into, the data needs to move in the right way. 

For example, moving a multi-terabyte database by "trying to suck it through a very thin straw is going to take a very long period of time," Dawes said. "You may have to adjust your migration methodology based off the size of the data." 

That might include moving in parts, copying the database onto an external device then moving it over, or using a vendor or public cloud can replicate parts of the database. Moving in these ways also means mapping out how data syncs, and what new pieces might be missed during the migration, and reconciling those differences.  

3. Don't test

Testing is more challenging than many organizations think because of how many applications an organization typically uses, said Dawes. In order for companies to run a test, the application needs to be in the testing bubble too. 

If the organization only has one license, it can ask for an additional, temporary license from the vendor, though Dawes warns the vendor may charge for it for one year. 

Tests also need to work through security issues, Dawes said. For example, if payroll is migrating, it needs to be able to connect to the organization's bank. The test needs to be done with the bank too, which may mean asking the bank for a testing area on their side. 

4. Don't have a backup plan

In a perfect world, day to day operations won't be impacted, and employees won't feel anything amiss after the migration. 

"The only thing they would notice is an improvement," Hall said. "However, it's important to let them know that something's happening. You don't necessarily have to give them all the details so that in the event of something going a little wonky, they'll be a little more understanding." 

Enterprises should have roll back plans in case something goes really wrong, Dawes said. That also means creating remediation plans with vendors, and having those vendors track their processes during and after the migration to make sure it all works.

After 24 to 48 hours, rolling back will be a challenge, Dawes added, which is why planning and testing are so important. Making sure both are done completely are more likely to mean a successful migration, or one where issues can be identified and remediated quickly if they do come up.