Organizations may decide to migrate their applications and environments in order to streamline operations, improve operational efficiencies, and save money. Unless important steps are taken in planning and implementing the migration, such migrations may fail, costing these organizations credibility, money, and, potentially, their data. In this blog, we’ll explore some of the steps required to perform a successful migration.
There are many reasons why an organization may want to perform a migration. Two primary reasons are listed here:
- the organization may decide to use a smaller set of tools than it currently uses, or it may decide to use one set of tools to replace those already in use.
- the organization may have multiple test applications and want to roll all the tools into one.
The end result of a migration should be increased efficiencies and reduced licensing fees, when fewer applications are needed. In order to perform a successful migration, certain steps must be taken:
Perform an inventory. Inventory all the tools in your enterprise. Work with your stakeholders to identify the feature sets in use; determine the benefits of using each tool. Once you figure out why each tool was in place (perhaps a certain tool was used for a particular purpose, or due to budget restrictions), you will have a better idea of the features a tool needs in order to be migrated. If the application that your organization will be using doesn’t provide the tools necessary for stakeholders, the migration will not be successful.
Look at the features of each tool. This will involve more people in the organization; once people realize what’s happening, they’ll want to be involved as well.
You should look at a granular level to understand what’s required during the migration – how much data will be moved, how workflows will be affected, how a migration will impact the various teams and departments whose tools are being migrated, and the impact felt both before and after a migration. Typically, this effort will involve many workshops where different groups will meet to discuss their processes. There may be multiple groups that use different processes – different data types, and different methods – and this will give the larger group a reason to discuss what’s best for each individual group.
If possible, get the groups together to work out a common approach to making the migration.
Plan the migration. Set up the servers where the data will be migrated. Consider the amount of data being migrated, the number of users to be supported, the size of the servers, and the capacity of the necessary data stores. This is an important step that should be included on the project plan.
Work out the technical processes required to migrate data. This may be as simple as exporting the data from an old system and importing it to the new system. There may be business rules to follow, and you may have to write development specs. Depending on the application and its capabilities, you may need to design the migration process.
You must figure out the destination applications and the data necessary to migrate, as well as write the scripts needed for performing the migration.
Test your migration. Migrate the data to the new system – make sure to migrate the dashboards, reports, and workgroups, and set up the data structures that will receive the exported data. It’s probable that you’ll be combining multiple data sets into a single set – determine an order of priority for the data, then migrate, combine, and review it.
You should, of course, migrate the data into a test system. The users should review the data in the test environment. Ask for feedback, and incorporate the changes users require. Migrate and test. Review with the users. Migrate and test again, and again have the users test and review the results. This may require several test sequences before the users are satisfied with the results of the migration and comfortable working in the new environment.
During testing, be certain to modify training so that users will be able to use the new system’s features once the final cutover to the migrated system is accomplished.
Once the “final” cutover has been performed, you should pilot test it, and run it for a few months until the stakeholders are satisfied with the migration. The process of migration may take many months.
There are a few things to consider, both before and after the migration has been performed:
- Moving the data is only one part of the total migration – you must also prepare users for the new environment.
- There will always be people who come into the migration planning and testing at late stages – don’t be surprised by people who will jump in late in the process.
- Some departments or teams may want to delay the migration of their data; they may want to eventually migrate their data, but will still want to use their current systems and cut over later. This delayed migration can cause many problems – especially when “live” data on “old” systems must be migrated and tested on the “new” systems.
ConnectALL from Go2Group is designed to automate the migrations, while keeping all data on supported systems in sync. For more information on how ConnectALL can integrate your systems and transparently migrate your data, please contact us.
Doug Bass is a certified Atlassian consultant and trainer and a certified ScrumMaster. He is an experienced systems architect with experience in distributed application design, database architecture, network design, and project management. Author of the first relational database for military applications in the UK and the first java-internet based chat application, Doug teaches classes in object-oriented design. He holds a Masters Degree in Information Architecture. He is a consulting partner for Atlassian’s product suite, and architect of several of Go2Group’s products including the CRM Plugin (JIRA and Salesforce integration), JIRA/Perforce plugin, and ConnectALL (a multi-application synchronization solution). Doug contributes his free time to the United States Power Squadron where he teaches classes on safe boating.