What is data migration, really?

- Migrating a file system or storage repository from on-premises to a company data center
- Migrating to the cloud
- Server upgrades
- Server consolidations
- Migrating to a document management system (DMS) or Enterprise Content Management (ECM)
- Implementing SharePoint (or increasing the use thereof)
- Implementing OpenText
- Transitioning from Novell Operating System to Windows
- Implementing Network Attached Storage (NAS) or a Storage Area Network (SAN)
- Remapping file paths into archives
- Folder restructuring
- Implementing Distributed File System (DFS).

What triggers a data migration?
Data migration standards that justify the transfer of files onto a new database include: • Routine upgrades of hardware and/or software. • The legacy system does not have enough storage capacity. • The business has been acquired by another company. • The business or government agency has merged with another entity that uses different software and/or different file naming conventions. • The organization splits into two or more organizations or units, each with a new name and requiring new file paths and filenames. • Someone orders all data storage moved off premises. The difficulty level of a data migration varies widely. The amount of data, the formats it’s stored in and the number and types of systems affected can all play a role.
Part 1: Planning Your Data Migration
Before you begin transferring data, take some time to determine exactly what data to transfer and what systems it affects. (Okay, this is kinda obvious. But, hey, it wouldn’t be a checklist if it didn’t start from the beginning. We’ll get to some lesser-known actions — and “gotchas” — before we are done.) Data migration is very strategic, so during the strategy development, assessment, and analysis stages, figure out what type of data you need to transfer, which systems use this data, and what other files the data links to. Data migration plan samples could give you some insight on how to structure your own plan, and are worth glancing over.
- How much data is there to migrate?
- How long do I estimate the project will take?
- What technology will this project require?
- What format is the data in, and will it need alteration for the new system?
- Do I have any duplicate or obsolete content that I can omit from the migration?
Have you checked your network for any obstacles to data transfer?
If you’re transferring data over a network, it’s important to have the most bandwidth you can. Check for firewalls that might delay data transfer. Firewalls are responsible for a large quantity of low-speed data flows instead of only a few high-speed flows. When attempting to send data through a firewall that’s faster than its internal processor can handle, the firewall has trouble handling those bursts of data. This can result in packet loss. Packet loss occurs when data traveling through your network fails to reach its destination and can create serious performance issues.
Have you developed a map of what data needs to be migrated?
Before beginning your data migration project, develop a map of what data needs to be migrated. Develop a data migration plan example, and then set up your map to fit that template. Your map should include where your files are and what they’re connected to. To maintain link integrity during data migration, include parent/child files in your map. This will help you make sure that once the transfer is complete, employees aren’t stuck dealing with broken links.
- A list of all details for the original source of data.
- Connections from the original data to their corresponding targets, providing any relevant information from the data directory.
- Any rules or stipulations for data that may need to be manipulated to move correctly through the network. Settings of interest could include default and mapping values as well as fields that need to be combined.

Have you done a landscape analysis to determine what systems the migration will affect?
Data migration usually focuses on the core and target systems. However, these two systems are rarely the only ones affected. Prevent broken links during migration by doing a landscape analysis. Landscape analysis is mostly research done by an organization’s competition and industry in general. Doing this analysis is advantageous to your company since it helps you:- Determine the best strategies and moves to make for the greatest chance of success
- Catch any design flaws before they become a nuisance
- Gain a competitive advantage over any competition
- Receive feedback on projects already underway
Have you identified software necessary to complete the migration?
Once you’ve identified the systems, amount and type of data you’ll be migrating, you’ll need to choose software to help you move the data to the target system. There is a range of different data migration software available. However, it’s a good idea to pick something specific to the type of data you’ll be migrating.
Imagine the “bad” things

- Underestimating the time the project will take to complete
- Trying to transfer too much data or alter a large amount of code at once
- Migrating data that is outdated and no longer needed
- Failing to take advantage of data migration tools
- Forgetting to conduct baseline tests to evaluate results after migrating is complete
- Failing to institute a rollback plan in case a new version faces instability
- Understanding how to perform proper validating testing and implementing those techniques into the data conversion project plan
Part 2: Figuring Out How to Transfer Data

Have you accessed your data?
If you don’t already have the full access you need, get access to your data early in the data migration process. This will save you a lot of grief down the road. Check out individual files. See what types of security permissions they have. Will you need to change these permissions during the transfer? What types of security permissions will they need in the new databases? Are there are any quirks in how the database is used that you’ll need to account for? Actually looking at your data will let you test out these hypotheses.Do you have a plan for validating the data transfer?
Validating the data transfer is a crucial step of a data migration; after all, corrupt or lost data is often a costly problem. Planning for data validation from the get-go is the way to go. There are three types of data validation possible:- Validating random samples
- Validating subsets of data
- Validating the complete data set

Do you have a recovery plan for data that didn’t transfer properly?
Despite your planning and testing, some of the data might not transfer properly. This can include minimal issues like using the wrong delimiter, or the core and target columns using different units of measurement. But it can also include major issues like data loss and corruption. Two issues you should consider now include:- Semantic data and file naming conventions: It’s common for departments to develop their own file naming conventions, or to use database fields in unusual ways. This usually isn’t a problem. But when you’re transferring data to a new system, it’s important to understand your users’ idioms. If you’re transferring data used by a particular department, consult with them now to make sure that you understand any unusual ways that they input information. Consider getting employees from these departments to visually validate samples of their data.
- Data loss and corruption: During the planning process, you should also consider what to do if data doesn’t transfer. This is a situation where prevention is the best cure. Will you be able to access a backup of any corrupted data? What can you do to prevent data corruption from occurring? Consider things like cleaning and deduplicating data before starting the transfer. You can also use tools like LinkFixer Advanced to inoculate (protect) links before the transfer.
Part 3: Beginning the Data Transfer: Preparing Data for a Migration

Have you cleaned the data you’ll be transferring?
Cleaning data before migrating it is significantly easier than cleaning it after. It can also cut down on problems with corruption and data loss in the target system. Extract, clean and deduplicate data before you transfer it. Fix any broken links and file type transformations in this stage.Have you checked to see whether any data should be archived instead of transferred?
Beginning a data migration process is a good time to review your data archiving procedures. You may not want to transfer all of your data. Some of it may be more suitable for archiving. This has the benefit of cutting down on work for you. Review or spot-check some of the data involved with the applicable department heads who use the particular files in question. If your organization has an Information Management (IM) department or group, you definitely should check with them as well. They will be very interested in what you are about to do. I can assure you of that. Be careful not to overreact, though. Although it’s tempting to archive data instead of transferring it, be realistic about what types of data need to be accessed regularly. Tip: Survey some of your key end users and your IM section to see what data they would be okay with archiving. They may save you a lot of time from having to restore something they regularly need. Conversely, they may also reveal some additional data that can be archived that you hadn’t considered. Have you tested the new hardware?
Part 4: Data Security Concerns
Protecting data is a growing concern for executives, financial officers, information managers, and public relations people. When you take on a data migration project, expect that many stakeholders will have concerns about security. Addressing data security concerns early in the process can get your project critical support from these groups. Be sure to obtain formal agreements from any governance you need to reach out to before the project’s start date. Ignoring protocol and security procedures can delay the project, or worse, get you directly in trouble.Have you identified relevant stakeholders from data security or privacy?
There aren’t many ways to stop a data migration project quicker than ignoring security. Security can be compromised in several different ways while preparing for data migration. When setting up systems and installing software, all those who are working on the project usually gain administrative rights. However, this larger pool of employees who have access to these privileges increases the likelihood of malicious actions occurring, whether intentional or unintentional. If you bring in outside help to assist with an extensive database migration project, whoever is lending their aid on the project now has access to your company. They have inside knowledge and can access systems they shouldn’t be authorized to enter, or execute tasks that do not align with standard procedure. Make sure outsourced help is familiar with the foundation of your company.
- Human Resources departments
- Accounting departments
- Legal departments
- Chief Financial Officers (CFO)
- Chief Information Officers (CIO)
- Third party software contractors
- Information Management (IM) personnel
Have you vetted the software and personnel involved in the data migration?
Many of the data privacy risks that a company faces come from careless, uninformed, or just plain disgruntled employees. That’s why it’s important to vet any personnel who will play a role in the migration. Determine the goals and responsibilities that each member of the IT team has, complete with milestones and time frames that different aspects of the job should be completed by. Do this by illustrating your team’s goals with some form of data migration plan template, documents, and PowerPoints for them to look over.
Have you reviewed industry statutes to ensure that you’re conforming to best practices?
If you’re undertaking a data migration project in a specialized industry, you may have to adhere to specific requirements governing how data is protected during transfer. This is particularly true of healthcare and financial organizations. Check to make sure that any software and migration methods you use meet these standards. Industry best practices are also a good way to get management on board with the data migration.Part 5: Getting Leaders to Buy-in to Your Data Migration
Getting business leaders to buy into a data migration project isn’t always easy. Neither executives nor users always understand the benefits of migrating data to a new format or system. More than a few IT professionals have found themselves struggling to get funding and personnel for data migration. Be sure to fully understand the reasons that data migration is necessary, and know how to communicate those reasons clearly to someone who may have less experience in the IT field. Look at your goals for the project from a business standpoint and let that shape the rest of your decision making. Use empathy, think like an executive, and try to understand what benefits they would care about.Have you set realistic deadlines and deliverables?

Do you have an adequate budget for this project?
We know this doesn’t always happen, but it’s good to know how much a data migration project will cost up front! It can help to get leadership buy-in if you align the data migration with other company goals, like increased productivity or cost cutting. To get people to support the needs of the data migration, focus on how the new data format will help the company. If you’ll be saving money by turning off an old database or server, let people know.Do you have the right personnel for this project?
Think beyond the IT department when you consider personnel. Try to get subject experts who can help to confirm whether data has transferred over properly. It can also be helpful to find real users to test the migrated data. These real users are your best gauge of whether the new database or system is working properly. If you’re in a large office, consider delegating this to department heads.Do you have company buy-in?
For many business owners or organization leaders, data migration isn’t the most exciting topic (though they will suddenly get real “excited” if something ends up missing or messed up). Particularly for longer migrations or more technical topics, it’s important to get prior buy-in from leaders. One of the best ways to do this is to focus on the most important outcome: They will lose access to data that isn’t migrated. (This should get their attention.) Making sure that they still have access to their data is often enough to get users on board.
Part 6: Planning for After the Deed is Done
After wrapping up your project, there are a few more tasks you should take care of and monitor for the foreseeable future.Have you planned for decommissioning the old server or database?
Decommissioning the old hardware can get executives and users on board in two ways. First, phasing out the old program/hardware can be a cost-saver. Most executives are easy to get on board when there is a savings involved. Second, the fact that the old hardware will be turned off means users will no longer have access to data on the old hardware. This can help users understand that they will need to access data in a new format or via a new program. This can also make it easier to get users on board with the process of transferring data. Do you have a maintenance plan in place? The work’s not done simply because the data’s been migrated. You’ll also need to make sure that the data is maintained regularly. Some people identify employees in the relevant departments to maintain data, while others charge someone within the IT department with the responsibility of maintaining it. We’ve designed LinkFixer Advanced for both data migration and maintenance. You can even use it to repair links, in batch, that were broken during an earlier data transfer. Getting started with LinkFixer Advanced is easy. Download your free trial today!

Ed Clark
LinkTek COO
Leave a Comment
Recent Comments
- No recent comments available.