# SaaS Migration Project Plan Template > A practical project plan for migrating from any legacy SaaS to a new platform. Adapted to: ___________ → ___________ (e.g., Salesforce → Pipedrive, Mailchimp → Brevo, AWS → Hetzner) > > Source: BetterInEurope · betterineurope.eu · Free to use, modify, and share. --- ## Project Metadata | Field | Value | |---|---| | Project name | | | Migration owner | | | Start date | | | Target completion date | | | Source tool | | | Target tool | | | Affected users | | | Affected systems / integrations | | --- ## Phase 1 — Discovery & Decision (Week 1) **Goal**: Understand exactly what you're moving and confirm the destination is a fit. - [ ] **Inventory current usage** - Number of active users - Number of records / data volume (contacts, deals, files, etc.) - Custom fields, automations, integrations in use - Storage size and growth rate - [ ] **Identify integrations and dependencies** - List all third-party services connected - Document API endpoints currently in use - Note any business-critical workflows - [ ] **Trial the target tool** - Sign up for a free trial / set up a test instance - Import a small sample of data - Validate the most-used workflows still work - [ ] **Gut-check the data export path** - Confirm export format (CSV / JSON / native format) - Confirm export includes attachments, metadata, audit trail - Confirm import path on the target side accepts that format - [ ] **Confirm regulatory and procurement fit** - Data Processing Agreement (DPA) reviewed - Data residency confirmed - Internal sign-off from legal / privacy (if applicable) - [ ] **Make GO / NO-GO decision** --- ## Phase 2 — Planning (Week 2) **Goal**: Build a written plan everyone agrees with before touching production data. - [ ] **Define success criteria** - What's "complete"? (e.g., zero data loss, all users migrated, all integrations working) - What level of disruption is acceptable for end users? - What's the rollback plan if something fails? - [ ] **Stakeholder map** - Who needs to know about this migration? - Who needs to approve specific stages? - Who provides support during cutover? - [ ] **Communication plan** - User-facing announcements (when and how) - Internal team coordination - Customer-facing communication (if applicable) - [ ] **Risk register** - Top 5 risks identified - Mitigation for each risk - Owner for each risk - [ ] **Budget** - Subscription costs (parallel-run period included) - Migration tooling / consulting (if any) - Internal team time --- ## Phase 3 — Setup (Week 3) **Goal**: Get the destination tool ready to receive data. - [ ] **Provision target environment** - Create accounts / workspace / organization - Configure billing - Apply security baseline (SSO, 2FA, IP allowlists) - [ ] **Replicate structural elements** - Custom fields - User roles and permissions - Templates / workflows / automations (skeleton only) - [ ] **Connect integrations** - Set up critical integrations on target - Test each integration with sample data - Document any integration gaps - [ ] **Test imports with sample data** - Import 5-10 records first - Validate field mappings - Identify edge cases (special characters, large fields, attachments) --- ## Phase 4 — Migration (Week 4) **Goal**: Move the data without losing anything. - [ ] **Schedule the migration window** - Choose low-traffic time (typically weekend) - Notify all stakeholders - Lock writes on source system if possible - [ ] **Final export from source** - Export complete dataset - Verify export integrity (record count matches) - Store export in encrypted location - [ ] **Import into target** - Run full import - Validate record counts match export - Spot-check 20+ records across categories - [ ] **Migrate attachments / files separately if needed** - Confirm all files transferred - Validate file integrity - [ ] **Run automations / workflows in test mode first** - Trigger each workflow manually with test data - Confirm expected outputs --- ## Phase 5 — Parallel Run (Weeks 5-6) **Goal**: Both systems running simultaneously, primary traffic on target. - [ ] **Switch primary use to target tool** - All new records go in target - Source system becomes read-only for verification - [ ] **Daily reconciliation** - Counts match between systems - Any sync gaps identified and patched - [ ] **User support** - Office hours for migration questions - FAQ document for common issues - Track issues in a shared log - [ ] **Performance benchmarks** - Compare key metrics (response times, throughput) - Validate target meets or exceeds source --- ## Phase 6 — Cutover (Week 7) **Goal**: Decommission source, fully commit to target. - [ ] **Final data sync** - Last incremental export from source - Last incremental import to target - Verify nothing was lost in the parallel period - [ ] **Disable integrations on source** - Turn off webhooks, API connections - Remove DNS entries / forwarding - [ ] **Cancel source subscription** - Schedule cancellation for end of billing period - Export and archive any data needed for compliance - [ ] **Update internal documentation** - Update runbooks, onboarding docs, training materials - Update integration credentials in 1Password / Bitwarden / etc. - [ ] **Send completion announcement** - Inform users the migration is complete - Highlight any new capabilities now available - Thank the team --- ## Phase 7 — Post-Mortem (Week 8) **Goal**: Learn what to do better next time. - [ ] **Hold a retrospective** - What went well? - What went badly? - What would we do differently next time? - [ ] **Document lessons** - Save lessons in your team's wiki - Update this template if you're going to use it again - [ ] **Measure success criteria** - Did we hit the goals defined in Phase 2? - What was the actual cost vs budgeted? - What was the actual timeline vs planned? - [ ] **Celebrate** --- ## Common Pitfalls to Avoid - **Underestimating attachment / file migration time.** Files often take longer than expected to transfer. Plan for 1-2 days of dedicated file migration time on top of structured data. - **Forgetting integrations.** That one Slack notification, that one Zapier workflow, that one webhook — they will break. List every integration explicitly. - **Not running parallel long enough.** Two weeks is usually right. One week is too short to catch monthly automations or low-frequency edge cases. - **Skipping the trial.** "We know what we want" is not a substitute for actually trying the target tool with real data before committing to the migration. - **Not communicating with users early enough.** Surprise migrations create resistance. Announce 2-3 weeks ahead, even if the work won't impact users directly. --- ## Need a Sanity Check? If you'd like a second pair of eyes on your specific migration plan — or you want to share what worked / didn't — email us at hello@betterineurope.eu. We're building a public knowledge base of EU-specific migration experience. --- **License**: This template is offered under Creative Commons Attribution 4.0 (CC BY 4.0). Use it freely, modify it, share it. If you use it in a public context, a link back to [betterineurope.eu](https://betterineurope.eu/) is appreciated but not required.