Checklists to Frame the Flight: The What’s What of Migration
We hear about migration pretty frequently these days. As our organization grows and matures, we grow our business intelligence and begin see the clear need to optimize the technology that is supporting our process. More simply put, we find that different systems will better support our business. Below we will outline the what’s what of migrations – what exactly it means, what factors to consider, what it looks like and more.
WHAT is a migration?
Simply put, migrations comprise of moving data from one environment to another. As you can imagine, this encompasses a lot of different scenarios, outcomes and motivating factors. We like to think of migrations in four primary buckets:
The following are common scenarios we see:
Migrate from legacy systems
Consider these 3rd Party Application Migrations, for example, moving of data from a non-Atlassian source to an Atlassian Application, like Zendesk to Jira.
- Applications that are available in the JIRA Importer Plugin
- Other Applications (e.g. VersionOne, Rally, etc)
Consolidate instances
Merging data into a target environment that already has existing data
- Merging Server data to Server
- Merging Cloud data to Server or Merging Server data to Cloud
- Merging Cloud data to Cloud
Server to Cloud or various directions
- Moving Server to New Server or AWS/Azure/GCP Cloud
- Moving Cloud to New Server or AWS/Azure/GCP Cloud or Data Center Deployment
Integrated work systems
Leveraging data from more than one system, for example, SalesForce or other CRM with Jira.
WHAT to consider when taking on a migration
Migration, as it is used in our case, is very aptly named. It is a massive move and a huge undertaking. Consider it to be like moving homes (but on a grander scale). Sure, you can organize your possessions, box them up, pile up your car, make runs back and forth, unload, unpack and reorganize. It is just a very stressful and time consuming process. That is why there are movers and that is why there are specialists who can do the migration grunt work for you. In either instance, you will need to take some key questions into consideration before getting underway.
- What applications need to be migrated?
- Where are the applications hosted? (Server, Atlassian Cloud, Atlassian Data Center)
- What application versions they are on?
- What is the general application instance size? Users? Projects?
- What Add-ons or integrations will be used?
- How users are being managed? (Internal Directory, LDAP/Active Directory, Crowd, myAtlassian)
- What Server Operating System will be used?
- What Database Type will be used?
WHAT a sample migration plan looks like (include graphic?)
Of course, a test migration is a necessary and critical component in making sure that you see zero data loss, identify any possible gaps or experience any bugs. After the test is a success, you can expect smooth sailing. Here is what a basic migration looks like.
- Identify Source Data – fields/data from your Source system that you want to bring over to JIRA and custom fields
- Setup Target System – Configure JIRA’s workflow and fields
- Extract Data from Source
- Transform & Prepare Data and Scripts for Target
- Load Data into Test Target System
- Validate Data Migration
- Repeat steps 3-6 for Production Migration