Checklists and Tools for Software Migration Planning

In this article, software migration is a catchall for many types of migration efforts that your organization might have to make. Here is a list of many different types of assets you might need to migrate at some point.

What is Application, Program, and Software Migration

Application, app, program, and software migration all refer to the same type of transfer: the process of moving an application from one environment to another (like from an on-premises enterprise server to a cloud-based environment, from one server to another, or from cloud-to-cloud). This can refer to applications custom-built on platforms like Microsoft Azure, the Google App Engine, Force.com, MySQL, or Amazon Web Services. Software migration is one of a few types of migrations that can be managed and automated entirely by a third party middleware solution. 

Software migration can also be a more simple movement of installed applications and data from one piece of hardware to another, such as your team all getting new computers, rather than moving an app’s development environment. This type of migration is significantly easier to manage in manual methods. 

Why Perform App, Program, and Software Migration?

Migrations of this type are done to improve efficiency or bring all applications from a legacy system into a current one. Often, organizations want to virtualize their software, meaning to disassociate it with operating systems and host the programs in separate environments for sandboxing at runtime. Here are some migration scenarios:

Example 1: You want to move your team using Adobe Creative Cloud (CC) from old PCs to new Macs. You need to ensure that once team members are working on Macs with Adobe CC installed, they’re still able to use paths to the server to access all creative assets.

Example 2: Your team uses custom software developed on one type of cloud environment  - like Amazon Web Services (AWS) - and now your organization is moving en masse to Google Cloud Platform (GCP). You need to map each piece of functionality your app had on AWS to GCP, despite the major differences in how each environment operates.

What Does Success Look Like?
Successfully migrating software from one environment to another means all users are able to access their accounts with no missing data or functionality.

Enterprise Resource Planning Migration

Enterprise Resource Planning (ERP) software is a specific type of software that integrates with other applications and automates many backend office functions like HR, product planning, sales, and marketing into a single interface. ERP migration is similar to other software migration, but involves significantly more risk because of how many business-critical functions it contains.

Why Perform ERP Migration?
Because of the massive complexity, integral nature, and significant investment of ERP systems, many large companies don’t migrate off of the platforms and systems they have installed for years. However, rapid changes in technology cause many features of new ERP systems to be out of reach, so there is limited talent that can or wants to work with a custom-built legacy ERP system. Additionally, global compliance is often a concern for enterprise-level companies, and those changing standards can apply to ERP. 

Example: After a decade of using a custom-built solution, your organization is facing top-down pressure to invest in Microsoft Dynamics GP, an industry-standard ERP. Despite being off-the-shelf, you need to make sure the new platform has all the same functions as the existing one.

What Does Success Look Like?
Success in ERP migration requires long-term commitment and planning. When the new system is running with global operations intact, and the internal team managing the system is up to speed, you can declare a success.

Operating System Migration

An operating system (OS) migration often refers to taking an OS (Windows, OSX, etc.) off a computer’s main hard disk and placing it on a virtual machine (VM) or a disk partition. It could also refer to moving from one operating system to another, transferring all data and software in the process.

Why Perform Operating System Migration?
Migrations of this type are done to increase speed or modernize an operating system (if it’s what’s being transferred), or to speed up all software and add new functionality (if you’re migrating from one OS to another).

Example: You’re running Windows, but just customized your machine with a solid state drive (SSD). Now, you’d like to move the OS from your HDD to your SSD to improve the speed of system-level functions.

What Does Success Look Like?
Successfully performing an OS migration means that all data has successfully ported, and that the new OS has no incompatibility with previously-accessible functionality. Standard features like the ability to run and interpret newly-installed software on this OS will work as normal. 

Database Migration

Database migration involves moving from one type of database to another, while maintaining other parts of your setup like its software and operating system. It could be changing the physical location of data, the type or provider of a database, or the format of the data. It often involves converting all data into a commonly-understood, transferable format before converting it again for its new location. It’s key to either write or license a program to process this migration.

Why Perform Database Migration?
Migrations of this type are usually done to upgrade or replace existing servers and hard disks, to perform server maintenance, to relocate a data center, or to consolidate all of a website’s assets into one physical location. 

Example: You currently handle all your application’s data through AWS, but you are launching unique hosting now that your data is large enough. You need to migrate all databases to a personally-managed server farm, and cannot risk losing any customer data along the way. 

What Does Success Look Like?
Successfully migrating databases simply means that no data is lost or inaccessible in translation.

Cloud Migration

Cloud migration involves moving applications, data, or other assets from on-site systems to a remotely-hosted environment, or from one cloud system to another. It often requires coordination with the third-party entities who control the cloud servers, which can have your data distributed between different locations.

Why Perform Cloud Migration?
Cloud migrations might be performed to consolidate an organization’s different teams’ data onto one service, or because another provider proved more cost-efficient or had other enhanced features like enterprise security.

Example: Your organization currently stores every vital file in G-Suite Drive, but now has installed Microsoft Office 365 enterprise edition on all machines, and therefore wants to transfer data to OneDrive for Business. It needs to move every type of file, including proprietary Google Docs, to this new storage solution. 

What Does Success Look Like?
Having all files readable and accessible are the key success factors in cloud migration. It’s also important to ensure that leftover private data doesn’t remain on a third-party cloud platform that you no longer have an agreement with.

Content Management System Migration

Content Management System (CMS) migration is the process of moving all existing content from one type of CMS to another. Difficulties lie in the nuances between how different systems both store and display this content, and the fact that there is usually quite a lot of content in organizations that utilize CMS.

Why Perform CMS Migration?
Organizations may want to migrate from one CMS to another if they decide to enhance their template website to a more custom provider, or an HTML-style editor to a more user-friendly “what you see is what you get” (aka WYSWYG) editor.

Example: Your company originally built a simple WordPress site and stored all of its blogs and articles on its internal CMS. Now that you’re scaling, you want to move to a custom-built Drupal environment overlaid on your new website and built from scratch by your developers. You need years of blog posts that display a certain way to make it from WordPress to Drupal without breaking links, failing to include photo and video assets, or losing simple tags. 

What Does Success Look Like?
When migrating content, success means that it all displays correctly and pulls the correct assets into the correct URLs. It should continue to be organized in a logical, easy-to-navigate way. 

IT Infrastructure Migration

Information Technology (IT) infrastructure migration is the process of moving all assets necessary for IT from one system to another. This can include assets like what ticketing and helpdesk software you use, where their backup servers are located or who provides them, or even just physically relocating the team and its hardware. What’s most significant about this type of migration is that IT typically mitigates risk and handles problems during other types of migrations. When IT systems are the ones being moved, a shell service is required to handle problems with the migration and problems for the rest of the organization.

Why Perform IT Infrastructure Migration?
Migration of IT systems might be done because you’re moving to a different office, getting a more reliable data center, or offshoring your company’s IT services altogether. 

Example: You’re downsizing your office in the city center, and moving all operations to a smaller location. Essential functions need to be moved to new on-site servers while the current infrastructure is physically transported.

What Does Success Look Like?
For IT infrastructure migration to be a success, business continuity must be maintained throughout the transfer of hardware and software, and the department must return to full functionality. 

As the previous section illustrates, there are significant challenges in any type of system or software migration. Some of the major challenges to be aware of are:

Price: Every software migration represents a financial investment on a company-wide scale, which means that there must be buy-in from stakeholders such as department heads, the CEO, and even the board of directors (depending on your organization structure). However, the price is not just measured in the cost to purchase the new software, license middleware, or hire third-party migration specialists: there is also the cost of internal resources devoted to the migration effort. This includes leaders and team members who must oversee and report on the effort, and the opportunity cost of those team members not working on another, more immediately-profitable venture. There is also the opportunity cost for other team members who are unable to perform their ordinary work functions as a result of systems being temporarily down. This can result in a prohibitive project budget, and be difficult to prove the value of migration against. 

Duration: Closely tied to price is the cost of time. It’s not just the downtime that some departments may face intermittently throughout the migration, or the time some senior team members must spend overseeing the project. Migration itself - especially for larger systems like databases and ERP software - can take years of planning and executing, because it’s too risky to take business-critical functions offline simultaneously. Long term projects can get unwieldy when you factor in team members who move on, and the necessary interdepartmental nature of most large-scale migrations. 

Commitment from Stakeholders: Due to the long duration of many migration projects, the commitment from key stakeholders can be tested. This is especially true as these department heads and team leaders may be responsible for budget, which will start getting spent immediately, and for return on investment (ROI), which may take years to manifest. A long term plan with clear targets and timeline estimates is the only way to mitigate this problem.

Privacy: Especially when it comes to moving to or from third-party systems (like cloud servers), privacy of data and business operations is a major concern. Oversight and ironclad SLAs are essential to any major migration that involves external companies and vendors.

Risk of Noncompliance: The entire purpose of a migration is to get the existing system running properly in a new environment. However, that isn’t guaranteed, and each environment has their own properties. If old systems end up having functions or operations that the new system is incompatible with, the project will take a serious blow. In a cloud migration scenario, it could be that the cloud platform you’re moving to doesn’t meet regulations for HIPAA compliance, or that they don’t access and store data in the same way. Issues like these need to be known far in advance of putting a plan into motion, so that workarounds can be developed or better vendors can be found.

Coexistence of Old and New Systems: For the sake of business continuity, no migration happens all at once. Therefore, you will likely have a large period of function and data overlap between the old system and the new. However, this won’t be in perfect parity, as the old system gradually drains into the new, in phases. During this time, there is a potential for redundancy, and confusion on the appropriate place to store data or the decision to duplicate or not. Having a solid plan with clear standards for each phase is the only way to ensure this doesn’t result in lost data or critical systems failures.

With all the above challenges to consider, you must carefully choose the method of software migration. Here are some of the primary ways to perform the task:

Traditional Uninstall and Reinstall

Best handled by: Your in-house team

Recommended when: The software in question installs relatively quickly and easily with few custom configurations. An example might be upgrading the enterprise OS your company uses. If it takes less time than any other option, it’s the best choice.

How it works: The traditional method is to simply uninstall old software on a machine and then reinstal new software on the same machine. This function could be handled by each team member individually, or by an IT data center on all machines in a few rounds. It is still best to centralize operations to make sure it is done to the same standard for all machines.

Reengineering

Best handled by: In-house specialists

Recommended when: Your legacy system is holding you back in innumerable ways, but modern off-the-shelf solutions are still lacking the specific function. It’s also a good idea when the company itself is built for these purposes, and has entire development or engineering departments.

How it works: This process will be completely custom, so how it works will be up to your team. The most important thing is to weigh the significantly increased costs of creating something proprietary to migrate to instead of picking an existing solution. While your organization is reengineering the platform, they should also be planning 1:1 function compatibility for the inevitable migration to their new system.

Re-hosting

Best handled by: Third-party migration software

Recommended when: There are no major changes necessary to your legacy applications, but a new platform is required for the sake of system modernization. It’s also ideal as a temporary step while preparing to remove legacy hardware, like old mainframes and outdated servers.

How it works: Re-hosting is the process of taking applications and data stored in one location, like a local server or computers, and moving them into a new hosting environment, such as a cloud platform or virtual machine. In the future, the applications and data need to be preserved for integration into newly owned hardware.

Package Implementation

Best handled by: Third-party migration software

Recommended when: You want to move off legacy applications, but don’t want to devote the resources to entirely re-engineer them. It’s especially well-suited to agile organizations.

How it works: By piecing together the desired functions to replace your old application from off-the-shelf solutions, you can tremendously cut down on cost and time investment to get a workable model running. These application packages get implemented in phases, eventually stripping the need to use the legacy system at all, so it can be removed.

Planning out a long-term, large-scale migration project can seem daunting, but it doesn’t have to be. Here are some resources to help you get started: a step-by-step guide to planning, some templates for tracking progress, and a checklist of what you need before you get started.

Step-by-step guide to Planning Software Migration

Ready to take the leap and migrate software? Follow these steps to help guide your process, ensure stakeholder buy-in, and get everyone onboard with the migration plan. 

1. Establish Your Cross-Functional Representatives. Because of the many hands required to see a software migration project through, and its long timeframe and far-off ROI, you need a champion in your corner - from every corner of the business. Get one key representative from each business function relevant to the software that’s moving - be it production, sales, accounting, IT or another department. These people will help you gain continued support of the project as it continues without ROI yet and comes under budget threats during, say, a lean quarter. 
2. Frame the Project for Stakeholders. Be it department heads, the C-suite, or the board of directors, lay out the plan and its essentialness to company longevity, attraction of new talent, and competitiveness in the marketplace. Set up what the project entails, what it isn’t, and lay out goalposts for each phase. Whenever it comes under review, you’ll have this initial framework you and stakeholders agreed upon.
3. Build a Team of Internal Experts. Find technical experts within your organization who can assist with each part of the migration, even if you’re ultimately using a third-party vendor or software for the migration. Put these people in charge of cleaning or writing programs to clean existing data, knowing where everything is stored, and understanding limitations of the platforms on each end of the migration. Depending on the size of your organization, each member of this team may lead their own small team to handle their portion of the project.
4. Take Inventory of Assets. There’s no way to judge a migration as successful if you’re not sure whether you lost any data along the way. In the case of data, some of your internal experts can check in on what is stored, making backups, and exporting to lightweight .CSV files or hard-copies (in the case of legal and other vital documentation). For software or applications, take inventory on each action and function possible with the software, how it interfaces with its databases, what it’s compatible with and what it isn’t, and the unique custom configurations it has that separate it from off-the-shelf software’s documentation.
5. Create a Risk Assessment Report. Using the section above on challenges, determine all relevant risks to the migration, including opportunity costs and compliance issues. This will be vital for getting final approval from stakeholders, and insulate project runners from being blindsided later. One of these risk assessment matrix templates can help you get started.
6. Determine Technical, Time, and Financial Requirements. Work with individuals in finance to work out long-term budget needs and rates of approval over the whole project. Work with IT, developers, and engineering to figure out the technical aspects and requirements, what method of migration is appropriate, and who will be forced into downtime at what stages of the project. Compile all of this to figure out realistic timing and checkpoints in the migration.
7. Create Project Management System for All Parties. With the data you gathered in the previous step, and all the teams you’ve assembled (technical, cross-functional, and stakeholder teams), create a common project management hub where everyone can see progress, send messages, attach files and findings, and generally lend visibility into the process. It should be intuitive for all users. Set up the project management software with the budget and time expectations at each phase agreed upon. You can present this information to the stakeholders for final approval prior to project kickoff, and use it to submit regular reports to them as they request. Learn more about stakeholder management in this article, The Definitive Guide to Stakeholder Management.
8. Perform the Migration in Phases. Depending on the appropriate methods, perform the migration and document every step. Use the project management tool to keep everyone informed and gather documentation. Along the way, when some employees inevitably leave or get added to the team, you can use this tool to quickly get them up to speed.
9. Test Cases After Each Phase. After each phase, test whatever you’ve migrated into the new environment, and document the outcomes. Regular testing and sandboxing will allow your team to catch problems early and regroup or change direction before data is lost and progress is wasted.
10. Results. Once the migration is complete, record final results, and compare it to the goalposts set up and tracked in your project management tool. Combine all documentation and deliver a final report to stakeholders, and begin reaping the rewards of your newer, faster, better software, operating system, cloud environment, or whatever else you migrated.

Software Migration Plan Templates

Now that you know the steps to follow to create a successful migration plan, these templates for Excel and Smartsheet can help with planning. 

Download Software Migration Plan Template

Excel | Smartsheet

Checklist Prior to Migration Project Launch

‌ Download Migration Planning Checklist - PDF

Many types of software migration require different tools to assist with the actual move, once your planning is completed in the project management tool of your choice. Here are a list of options and the type of migration they can handle:

As healthcare and technology continue to merge, there creates a need for increased data management, organization, and security. To overcome these hurdles faced healthcare organizations, implementation of effective data migration strategies help to facilitate a streamlined and secure move from manual to automated processes.

Additionally, healthcare organizations must ensure data security and safeguard protected health information (PHI) throughout the process of software migration. Patient portals, health history, and other private healthcare related materials must remain protected, and authorization to information must be limited. To ensure healthcare organizations can migrate software into their processes without disrupting compliance regulations, you need a powerful, real-time, and secure tool.

Smartsheet is a work execution platform that enables healthcare companies to improve work efficiency, scale business processes, and securely manage and store PHI, while meeting or exceeding all of HIPAA’s regulatory requirements. Streamline reporting, organize all necessary information in one centralized location, and set security and sharing settings to uphold data security standards.

Interested in learning more about how Smartsheet can help you maximize your efforts? Discover Smartsheet for Healthcare.

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.