A data migration plan is a document that defines what data you will move, how you will move it, who owns each step, and how you will prove the move succeeded. It covers scope, data mapping, testing, cutover, rollback and sign-off. Without one, the odds are against you: Gartner research cited by Oracle found that 83% of data migration projects fail or exceed their budgets and schedules.
This guide walks through a nine-step data migration plan built for teams moving work-management and ITSM data, such as Jira, ServiceNow, Azure DevOps, Salesforce or Zendesk. You'll also get a copyable data migration plan template and a before / during / after checklist. Along the way, we'll show where Getint fits in the migration process, and where it doesn't.
What is a data migration plan?
Data migration is the process of moving data from one system, storage location or format to another. A data migration plan is the operational blueprint for that move. It turns a high-level data migration strategy ("we're moving from Jira Data Center to Jira Cloud in phases") into concrete tasks, owners, dates and acceptance criteria.
It helps to separate three terms that often get mixed up:
- Data migration strategy: the approach you choose, such as big bang, phased or parallel.
- Data migration plan: the full set of decisions and tasks that execute that strategy.
- Data migration checklist: the testable items you tick off at each stage.
There's one more distinction that matters for work-management tools: migration vs. integration. Migration moves historical data, the records that existed before the switch, usually as a one-time project. Data integration keeps two systems synchronized as new work is created and updated. Many real projects need both: you migrate history first, then keep the systems in sync while teams move over. Getint supports both modes on the same platform, which we'll come back to in the steps below.
Why you need a data migration plan
Moving data is rarely the hard part. The hard part is moving it without data loss, broken relationships, surprise downtime or angry users. The numbers show how often that goes wrong:
- Most projects overrun. Bloor research, cited by Oracle, found that more than 80% of data migration projects run over time and/or over budget, with average cost overruns of 30% and time overruns of 41%.
- Cloud migrations slip too. McKinsey found that companies spend about 14% more on cloud migration than planned each year, and 38% saw migrations delayed by more than a quarter.
- Bad data is expensive. Gartner estimates poor data quality costs organizations an average of $12.9 million a year. Migrating dirty data just moves the problem to the new system.
- Downtime is costly. In ITIC's 2024 survey, 97% of large enterprises said one hour of downtime costs over $100,000, and 41% put it at $1 million to over $5 million.
A written data migration plan reduces these risks because it forces decisions early: what's in scope, what "done" means, who signs off, and what happens if something breaks during cutover.
There's also a timing reason for many Getint readers. Atlassian Data Center reaches end of life on March 28, 2029, when Data Center products become read-only and support and security fixes end. Existing customers can no longer buy expansions or upgrades after March 30, 2028. If your teams run Jira or Jira Service Management on Data Center, a migration project is coming, and planning it now gives you room to do it in phases.
Types of data migration
Most data migration projects fall into one of five types. Knowing which one you're running helps you pick the right data migration tools and the right people.
Getint focuses on application migration and cloud migration for work-management and service tools, where the challenge is less about raw data volume and more about preserving fields, statuses, comments, attachments and relationships between work items.
Choose a data migration strategy
Big bang vs. phased vs. parallel migration
Your data migration strategy decides how much risk you take on at cutover.
For most enterprise teams, phased migration is the safer choice. The catch is that during the transition, some teams work in the old system and some in the new one. That's where two-way synchronization earns its keep. With Getint, you can migrate historical items wave by wave and keep the remaining projects synchronized between both platforms, so nobody works from stale data.
The 7 Rs of migration
AWS describes seven migration strategies, often called the 7 Rs. They're mainly used for applications, but they're a useful lens for deciding what to do with each dataset:
- Retire: decommission or archive what has no business value.
- Retain: keep it where it is, or postpone.
- Rehost: lift and shift, with no changes.
- Relocate: move to a cloud version of the same platform without changes.
- Repurchase: replace with a different product, often SaaS.
- Replatform: move with some optimization, such as a managed service.
- Refactor: rebuild to use cloud-native features; the most complex option.
In a work-management migration, "retire" is the most underused R. Archiving dead projects before you migrate cuts data volume, cost and testing time.
Data migration steps: how to create a data migration plan
Step 1: Define scope, goals and success criteria
Start with business requirements, not tools. Write down why you're migrating (modernization, consolidation, platform replacement, Data Center end of life) and what success looks like in measurable terms. For example:
- 100% of in-scope issues migrated, with record counts matching per project
- Zero critical defects open at the end of user acceptance testing
- Less than four hours of downtime per migration wave
Then identify relevant stakeholders across IT, service and business teams, and agree who approves, executes, tests and signs off.
Step 2: Assess source systems with data profiling
Run a data assessment on every source system. Inventory projects, issue types, tickets, custom fields, users, comments, attachments, links and workflows. Profile field completeness, duplicates and formatting, and note which historical data still matters.
Document technical constraints too: source APIs, permissions, rate limits and dependencies such as other apps or automations. Getint's migration guide recommends auditing projects, workflows, custom fields and apps, and mapping external integrations before you plan waves.
Step 3: Design the target system and map fields
Confirm the target system is configured before any data arrives: projects, issue types, workflows, statuses, custom fields and permissions. Then build a field-mapping document that shows how each source field corresponds to a target field, along with any transformation rules.
In Getint, you create a migration integration, pick the two apps, map issue types, and then map fields in the UI. A few practical rules from Getint's documentation:
- Create matching fields in the destination first for 1:1 mapping.
- If a field type has no equivalent, map it to a custom text field with the "Use label from the other side" option, which transfers the value as plain text.
- Merge several source fields into one text field with the merge option or a custom script.
Users must already exist in the target system, because Getint doesn't create them. Plan user provisioning as its own task.
Step 4: Cleanse and prepare data
Data cleansing is where you protect data quality. Remove duplicates, fix inaccurate values, standardize formats and archive what you've decided to retire. Every record you don't migrate is a record you don't need to test.
Getint helps you leave clutter behind with selection filters. You can limit a migration by item IDs or a JQL filter, and set a time range based on creation or last-updated date, so out-of-scope records never move.
Step 5: Plan security, compliance and backups
Treat sensitive data as a first-class requirement. Your plan should specify:
- Encryption for data in transit and at rest
- Access controls and role-based permissions for everyone touching the migration
- Compliance needs such as GDPR and data residency
- Full, verified backups of source data before anything changes
Getint is ISO 27001 and ISO 27018 certified and SOC 2 Type 2 compliant. It's available as Getint Cloud or as an on-premises installation behind your firewall, which matters when data governance rules limit where data can travel.
Step 6: Build and test with a pilot migration
Never make your first run the real one. Pick a pilot project with representative data, including messy records, large attachments and complex custom fields, and run a dry migration into a test environment.
Test comments, attachments, links, statuses, custom fields and permissions. Compare source and target record counts. Then let business users run user acceptance testing on real workflows.
Getint's migration license includes a three-month sync license, so you can test the tool and your mappings before the full migration. Progress shows in sync logs and the latest runs, so you can trace any rejected record to its cause.
Step 7: Plan the cutover, freeze window and rollback
Cutover is the highest-risk moment of the entire data migration process. Write a runbook that covers:
- Go/no-go criteria: for example, pilot record counts matched, UAT signed off, no open critical defects.
- Freeze window: when edits stop in the source system for the wave being moved.
- Rollback triggers and owner: what failure forces a rollback, and who calls it.
- Communication plan: who hears what, and when.
In a phased migration with Getint, teams that haven't moved yet keep working, because their projects stay synchronized. That shrinks the freeze window to the wave being cut over instead of the whole organization.
Step 8: Execute, validate and reconcile
Run the migration wave by wave. In Getint, you choose the direction, decide whether items that already exist in the target are recreated, updated or skipped, and schedule the migration. If a mapping fails, fix it and resync only the affected fields on items you've already migrated, instead of starting over.
After each wave, validate data accuracy:
- Reconcile record counts between source and target per project
- Have business owners inspect samples of migrated data
- Verify workflow triggers and automations in the target platform
- Confirm users can reach the historical records they need
Step 9: Monitor and decommission
A successful migration doesn't end at go-live. Monitor data integrity and sync health, track unresolved records in an exception queue, and run a post-migration audit.
Document every mapping, filter, script and remediation decision for future audits. Keep the legacy system read-only until the business owner signs off, then decommission it. By default, Getint disables a migration integration once it finishes to prevent unintended updates. If you need ongoing sync, for example with a team that stays on another tool, you can switch continuous synchronization on instead.
Data migration plan template
Copy this data migration plan template into your project doc and fill in each row before you migrate anything.
Data migration checklist
Use this data migration checklist alongside the template. Every item should be testable. Tick items as you go: your progress is saved in your browser, and you can copy or print the list for your team.
Common data migration challenges
- Data loss or data corruption. Format incompatibility and failed transformations can leave lost or corrupted data. Fix: back up first, pilot, and reconcile counts after every wave.
- Poor data quality. Duplicates and stale records slow the move and pollute the new system. Fix: cleanse and filter before migrating.
- System downtime. Long cutovers disrupt business operations. Fix: migrate in phases and keep systems in sync between waves.
- Unsupported structures. Boards, dashboards, schemes and project settings often don't migrate cleanly with any tool, Getint included. Fix: recreate them in the target and include them in UAT.
- Late communication. Users who find out on go-live day resist the new system. Fix: share the timeline early and plan training.
Data migration best practices
- Start with a pilot project, not your most critical one.
- Archive before you migrate.
- Run at least one dry migration end to end.
- Move in waves and keep the remaining systems synchronized.
- Keep detailed logs to simplify troubleshooting and audits.
- Have a rollback plan you've actually rehearsed.
- Document as you go, not afterwards.
How long does it take? Getint's migration guide estimates about 4 to 6 weeks for small teams, 2 to 3 months for medium setups, and 6 months or more for large or complex environments.
How Getint supports your data migration plan
Getint is an integration and migration platform for work-management, ITSM and CRM tools. It connects Jira Software, Jira Service Management, ServiceNow, Azure DevOps, Salesforce, Zendesk, Asana, Monday.com, ClickUp, HubSpot, GitLab, GitHub, Freshdesk and Freshservice.
Here's how it maps to the plan above:
Keep in mind what Getint doesn't do: it won't create users, copy project-level settings and schemes, or rebuild boards and dashboards. Plan those as separate tasks.
Moving from Jira Data Center to Cloud? Read our guides to Jira Data Center end of life and Jira migration with JCMA vs. Getint, or see the Getint migration guide. When you're ready, book a demo and we'll help you scope your first migration wave.
