Skip to content
Steps-for-Data-Migration-Final

IT Tips & Tricks

6 Steps to Create a Data Migration Plan: Everything You Need to Know

Published 13 October 2016

Updated 16 September 2024

Contents:

What is Data Migration, Really?
What Triggers a Data Migration?
Part 1: Planning Your Data Migration (Avoiding the Top “Gotchas”)
Part 2: Getting Leaders to Buy Into Your Data Migration
Part 3: Figuring Out How to Transfer Data
Part 4: Preparing Data for a Migration
Part 5: Data Security Concerns
Part 6: Planning for After the Deed is Done

What is Data Migration, Really?

Let’s start with a couple of basics. (I’ll be brief and get to the good stuff fast.)

The term “data migration” is actually quite broad and covers a whole gamut of types of data, activities and systems. Data migration is the process of transferring information from one system to a new system. This article focuses on one specific type of migration: moving data from one storage/management platform to another. This is often referred to as “storage data migration.” This can include transferring data between different file formats and different storage types. Examples include:

  • Migrating to SharePoint® Online or SharePoint Server Subscription Edition.
  • 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 OpenText.
  • Transitioning from Novell® to Windows®.
  • Migrating to SharePoint® Online or SharePoint Server Subscription Edition.
  • 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 OpenText.
  • Transitioning from Novell® to Windows®.

If you’d prefer not to have to deal with potential transfer issues, of which there are a lot, you are not alone. Consider hiring a migration consultant who deals with these types of problems every day and will ensure a seamless data transfer.

  • Implementing Network Attached Storage (NAS) or a Storage Area Network (SAN).
  • Remapping file paths into archives.
  • Folder restructuring Implementing Distributed File System (DFS).

(Currently, the majority of our customers are migrating to
SharePoint Online.)

So, how do we form a complete plan for data migration?

It begins with understanding the need for data migration, creating a data migration project plan template, executing the project and then conducting a data migration review.

What Triggers a Data Migration?

Here are some of the more common reasons you may need or want to do a data migration:

Serious problems including downtime, lost income, extra work and upset end-users can result from failing to adequately plan (not to mention lost weekends).

  • 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.
  • Your organization wants the convenience or the increased ease of long-range connectivity of the Cloud.
  • Moving to a system that supports code compliance such as HIPAA or a security standard such as ISO 8601.

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.

Whether you’re transferring a single database or undertaking a large-scale data migration project, it’s not just “important” to be prepared. Serious problems including downtime, lost income, extra work and upset end-users can result from failing to adequately plan (not to mention lost weekends). The purpose of this checklist is to help you avoid some of these perils.

Part 1: Planning Your Data Migration (Avoiding the Top “Gotchas”)

Part 1: Planning Your Data Migration (Avoiding the Top “Gotchas”)

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. I’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 project plan samples could give you some insight into how to structure your own plan and are worth reading.

Note: I meant it when I said, “and what other files the data links to.” At first glance, this may appear to be just innocuous advice. But in the real world, this has actually been one of the “gotchas” that many IT pros have failed to account for, sometimes to their embarrassment.

AdobeStock_721579671

We rarely undertake a journey without our GPS or a map of some sort. Why would a data migration be any different? Planning and mapping your migration journey will save you time and prevent otherwise unforeseen pitfalls.

It’s easy to forget just how connected data is to other data. Users all across your organization are connecting (linking) data into their files all the time. They think nothing of it. And they don’t ever mention it to anyone in IT. If you change one thing, say a folder name, for example, you could be affecting other data somewhere else in your system in ways you hadn’t thought about yet. More on this will follow.

In my experience, these are some important questions you might want to ask yourself:

  • 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?

Outdated or redundant files frequently occur when reviewing data from old systems. So, take the extra time during this stage to weed out this content. This will speed up the migration process by lightening the data load that will need transferring. It can also save your organization a lot of money if you are migrating to a platform that charges extra when the amount of your data exceeds a certain limit (such as Microsoft does with SharePoint Online, for example). Why pay more to keep old or duplicate data that’s never needed?

Establishing a time frame using an accurate means of assessment and having the adequate tools you need are also important in pre-migration planning.

It’s easy to forget just how connected data is to other data. Users all across your organization are connecting (linking) data into their files all the time. They think nothing of it. And they don’t ever mention it to anyone in IT. If you change one thing, say a folder name, for example, you could be affecting other data somewhere else in your system in ways you hadn’t thought about yet. More on this will follow.

In my experience, these are some important questions you might want to ask yourself:

  • 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?

Outdated or redundant files frequently occur when reviewing data from old systems. So, take the extra time during this stage to weed out this content. This will speed up the migration process by lightening the data load that will need transferring. It can also save your organization a lot of money if you are migrating to a platform that charges extra when the amount of your data exceeds a certain limit (such as Microsoft does with SharePoint Online, for example). Why pay more to keep old or duplicate data that’s never needed?

Establishing a time frame using an accurate means of assessment and having the adequate tools you need are also important in pre-migration planning.

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 available that you can use without impacting your day-to-day networking requirements. A dedicated network could be used to ease this process.

AdobeStock_38751832

Is your firewall slowing your
data transfer?

Check for firewall restrictions that might delay data transfer. Firewalls manage a multitude of data flows ranging from small to large data packets, processing data headers for each packet. It is important to not create a processing overhead that is too large to process in a timely fashion. When attempting to send data packets through a firewall that are larger than the firewall’s internal processor can handle, the firewall has trouble handling the size of those packets.

Another example includes outdated firmware causing a lag in network data transport. 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. Ultimately, a stable and reliable internet connection is a fundamental requirement to ensure no problems transferring data.

In addition to adjusting your firewall to allow for full utilization of the bandwidth you have made available, consider transferring data when there are fewer users — or even better, no users — currently connected to your data servers. Schedule data migration for overnight if possible.

If you must share a network during data migration, consider throttling your usage to prevent slowing down the network for other users. If you’d prefer not to have to deal with potential transfer issues, of which there are a lot, you are not alone. Consider hiring a migration consultant who deals with these types of problems every day and will ensure a seamless data transfer.

There aren’t many ways to stop a data migration project quicker than ignoring …

Have you developed a map of what data needs to be migrated?

Whether you’re putting together a SharePoint migration plan or some other data migration project, it’s important to 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.

If you are not yet 100% familiar with what is meant by “parent file” and “child file”, click here to get a brief definition.

Structure your data mapping specifications to encompass the critical attributes of each piece of information that transfers through your data migration activities. Use the following elements to form a data migration template:

In the real world, this has actually been one of the “gotchas” that many IT pros have failed to account for, sometimes to their embarrassment.

  • 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.

Data migration mapping templates can also be found online and used to better visualize how to set up your own. They are most commonly done in spreadsheet software such as Microsoft Excel™ or Google Sheets™.

Traditional data mapping techniques can be supplemented with software such as our link preservation tool that allows for easy transfer or modification of files without the risk of the file links becoming broken
or corrupted.

Bonus Tip: Print out your map before you begin migrating your data (at least in PDF form). Yes, it’s old-school, but it’s worth having a backup of the map before you begin the process. Mapping can help you catch errors before you start moving stuff around.

Data migration mapping templates can also be found online and used to better visualize how to set up your own. They are most commonly done in spreadsheet software such as Microsoft Excel™ or Google Sheets™.

Traditional data mapping techniques can be supplemented with software such as our link preservation tool that allows for easy transfer or modification of files without the risk of the file links becoming broken or corrupted.

Bonus Tip: Print out your map before you begin migrating your data (at least in PDF form). Yes, it’s old-school, but it’s worth having a backup of the map before you begin the process. Mapping can help you catch errors before you start moving stuff around.

Have you done a landscape analysis to determine what systems the migration will affect?

Data migration usually focuses on the host and target systems. However, these two systems are rarely the only ones affected. For example, DFS shares that make use of specific items through an existing UNC path — such as Excel sheets or other corporate documents that exist on the DFS — may also be affected. Take inventory of your data stores and links with a landscape analysis. Landscape analysis (an internal audit) is research done on your organization’s known and unknown existing data stores. Doing this analysis is advantageous to your company since it helps you:

  • Determine exactly where all of your data stores are located and the best strategy to move them.
  • Find previously overlooked configurations that would restrict access to data — even if
    non-critical.
  • Easily structure your data so that accessing it is not difficult
    and confusing.
  • Put together a migration plan that includes an overview of the stages of your migration.
  • Take inventory of any data containing links that will break during the migration and determine how to protect them to avoid data loss.
  • Find previously overlooked configurations that would restrict access to data — even if non-critical.
  • Easily structure your data so that accessing it is not difficult and confusing.
  • Put together a migration plan that includes an overview of the stages of your migration.
  • Take inventory of any data containing links that will break during the migration and determine how to protect them to avoid data loss.
AdobeStock_319264151

Data loss can have some unexpected side effects.

Understanding the requirements of a data migration will ensure you have a better overview of the task at hand, give you a better understanding of the systems that make use of your data (outside of your host and target systems, such as a DFS) and further help you to determine the best course of action required for your migration.

Data protection is where LinkFixer Advanced™ comes into play. It has a feature called “Inoculate” that automatically creates associations (sort of like a secondary means of linking) between each parent file and all its child files before they’re migrated. After migration, the “Cure” function acts as a batch re-link operation. A tool that automatically handles links during your data migration can save you thousands of hours.

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 migrate 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.

There are different types of data migration. The most common is data storage migration, which is simply a matter of moving data from one storage system to another. However, you also can use data migration for applications such as a company changing customer relationship management (CRM) software. Business processes can also be migrated to better align with current operations.

Most of your failed data migration projects (heck, most failed IT projects of any kind) fail due to lack of imagination in the planning stage.

Data storing drives are also commonly migrated onto newer technology platforms for easier accessibility and enhanced reliability. One such example could include a migration from an older NAS to a newer model. Another example could include moving data from an older mechanical drive-operated system to a solid-state drive-operated system.

Specific processes take place (while converting data) that differ from one another as well. Exporting and importing is one type of process, and to expand on the example used in the paragraph above, could include uploading a list of client information from Excel to a CRM software which requires the data to be in a neutral format. Scripts prepare data and move things around to fit a new data model better. When the data set is too large for a simple script, an extract, transform, and load (ETL) tool is preferred and can automate many elements of the data conversion project plan.

The best data migration software depends on what type of data migration you are trying to achieve and which processes require assistance. Data migration managers, NAS virtualization software and storage area networks all have their applications. Do your research to determine what best suits your needs and which are the best tools you can use for the job.

Can you imagine the “bad” things?

I published the following in an article in 2015: “Most of your failed data migration projects (heck, most failed IT projects of any kind) fail due to lack of imagination in the planning stage. Notice that I didn’t say ‘lack of planning.’ (I wouldn’t insult you like that.) But there is an insufficient amount of imagining what the various bad outcomes of various actions might be so that you can prevent the bad things from happening, or at least be ready when they do.” This is still true today.

Take a moment and do this exercise. Imagine the potentially avoidable bad outcomes. It could save you untold heartache.

Mistakes that IT professionals typically face include the following:

  • 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 validation testing and implementing those techniques into the data conversion project plan.

While data migrations sometimes fail due to unavoidable causes, more often than not the failure is due to human error that could have been prevented by foreseeing common mistakes and potential unsavory events and then using the correct techniques and software to allow the process to go as smoothly as possible.

Part 2: Getting Leaders to Buy Into 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 why the data migration is necessary and know how to communicate those reasons clearly to someone with 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?

More than half of all data migration projects go over the deadline. Therefore, it’s important to be upfront about realistic deadlines for your project.

It can help to group the data by functional areas. Your data map can help you to identify these areas and schedule realistic deadlines. Be sure to allot more time to resource-intensive areas. If you’ve identified areas with variations in how the system is used, consider allotting extra time for testing and transferring data.

One way to increase buy-in from executives and users is to schedule a few wins early in the data migration project. Users who see the project’s benefits are more likely to support it.

If you’ve identified an area that could produce immediate benefits, consider pushing it to the front of the data transfer project. Look for low-hanging fruit to use as your “convincer.” For example, if your organization has an engineering department that has frequently complained of slow processing speed and you estimate that after the move to those two super-fast servers, these engineers are going to see a major speed and performance increase on their Computer-Aided-Design (CAD) files, consider moving them first and using the results as your “show car.”

Do you know any IT professionals with the time and resources to validate a complete data set?

Do you have an adequate budget for this project?

I know this doesn’t always happen, but it’s good to know how much a data migration project will cost upfront. It can help to get leadership buy-in if you align the data migration with other company goals, such as 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 been 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.

To repeat, one way to get the leaders on board with migrating is to build in some short-term wins up front in your project. These will let leaders see the benefits of the migration early on, and help keep them a bit more patient throughout the slower portions of the project.

Part 3: Figuring Out How to Transfer Data

Your next step in the planning process is to figure out how to transfer data. Test your hypotheses early and often during this stage. Corruption and data loss are two of the biggest risks in any migration project. Your data transfer method should help to minimize data loss. Good test cases can also cut down on the need for time-consuming manual validation.

Preventing file loss and data corruption can be achieved by backing up your files on a NAS (Network Attached Storage) or other external storage. Large USB drives are surprisingly inexpensive now.

Back-ups should be done habitually at a fixed time, rather than waiting for a data migration project to be underway. Viruses, theft and destruction of hardware all take place commonly, so regular backup of your files can help dampen data migration risks and safeguard your files in general.

I cannot overemphasize the importance of backups. Always, always, always have an up-to-date backup of your data. And test it. There’s nothing worse than being in a situation where you need that backup — and then discover that it’s not working for some reason.

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 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?

AdobeStock_299339612V3

Broken links are a sure-fire way to lose data during a migration. Protect your linked data.

Validating the data transfer is a crucial step in 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.

In an ideal world, it would be possible to validate the complete data set. But in the real world, do you know any IT professionals with the time and resources to validate a complete data set? Consider validating random samples or subsets of the data to save time and sanity.

Random sampling is advantageous in that it leads to a low bias of model performance, but can also lead to subsets that do not encompass all the data properly and provide high variance, resulting in an inaccurate test.

Validating certain subsets of data offers a better generalization of all the types of data in the transfer. It’s just important that you split the data properly to get a confident analysis.

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 a tool like LinkFixer Advanced to inoculate (protect) links before the transfer.

Part 4: Preparing Data for a Migration

Whether it’s duplicates, bad links or outdated formats, most data has at least a few issues. Clean up your data before you transfer it. This will cut down on the amount of data you’ll need to transfer, as well as the amount of data you’ll need to validate after the migration is done (and the amount of data you may have to pay for).

Have you cleaned the data you’ll be transferring?

Cleaning data before migrating it is significantly more efficient 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?

Review your data archiving procedures before your data migration. 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 should check with them as well. I can assure you that they’ll be very interested in what you are about to do.

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. This could 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.

Whether it’s duplicates, bad links or outdated formats, most data has at least a few issues.

Have you tested the new hardware?

One of the biggest mistakes in data migration is not testing the new hardware before you transfer data to it. Since most people transfer data from a smaller, outdated system to a newer, bigger system, they don’t bother to test the new hardware.

Unfortunately, this means that people complete a data migration, only to have the hardware break shortly after. Don’t be one of those people. Test your new hardware thoroughly before transferring data onto it.

Part 5: 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 security concerns.

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 assisting on the project now has access to your company data. 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 foundational security requirements of your company.

It’s also worth noting that you should be wary of what custom software and utilities are used throughout your data migration activities. Although they might do their job efficiently and save you time, overlooking specific security issues during the design of the application isn’t uncommon.

Our software designers at LinkTek are committed to ensuring that the products we offer to our customers are exemplary in performing the proposed function they are meant to help automate while not compromising any security measures.

Find out now who’s concerned with data security and data privacy issues at your business, and figure out how to address their concerns. Along with the IT department, consider the following groups:

Vet any personnel who will play a role in the migration.

  • Human Resources departments
  • Accounting departments
  • Legal departments
  • Chief Financial Officers (CFO)
  • Chief Information Officers (CIO)
  • Third-party software contractors
  • Information Management (IM) personnel

Identify their specific concerns and the data affected by these issues.

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 by which different aspects of the job should be completed. Do this by illustrating your team’s goals with some form of data migration plan template, documents or PowerPoints for them to look over.

This is also a good time to review who has what types of permissions to access confidential data by following the principle of least privilege. It’s far too common to have accounts that are either not in use (or belong to ex-employees) retain access to restricted files. Remove these permissions before beginning a data transfer to cut down on the risk of data breaches.

By the same token, it’s important to vet the software you use for a data transfer. Don’t just pick up any open-source file transfer software. Make sure the software you use is legitimate and well-regarded.

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 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 to decommission 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 companies appoint 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. Request your free trial today or call 727-442-1822 to speak with a knowledgeable LinkTek Consultant to get any questions answered.

AdobeStock_80911776

Want your next migration to be smooth as ice?

If, at this point, the mere thought of data migration is somewhat overwhelming, you’re not wrong. There are literally hundreds of variables and factors to take into consideration during both the planning and execution phases of a data migration. And believe it or not, there are people on this planet who thrive on it.

They’re generally referred to as migration consultants, although I think they seriously deserve a more heroic title. If you’re not the type of person who thrives on data migration, find someone who does. They have the knowledge, skills and temperament to get it done — while simultaneously reducing your stress and workload. And that sounds like a win-win to me.

Considering getting professional help (for your migration, that is)? To discover more about this option, visit the SharePoint Migration Consultants page. You can even schedule a free strategy session to discuss your specific situation.

By Ed Clark

EdV2

Ed Clark

LinkTek COO

View Bio

Feel free to share this article on your social media: