SaaS to Custom Software Migration: A 90-Day Playbook

Why does a migration need a playbook?

The decision is made. You are replacing a SaaS tool with custom software. The next question is practical: how do you get from here to there without disrupting the business, losing data, or creating a gap in capability?

Most migration failures are not technical failures. They are process failures. The build went well, but the data migration was treated as an afterthought. Or the team cut over too early, without parallel running, and discovered gaps in production. Or nobody planned for the month-end reporting cycle, and finance lost visibility at the worst possible moment.

A structured 90-day playbook prevents these failures. It breaks the migration into five overlapping phases, each with clear inputs, outputs, and decision points. The timeline is compressed but realistic for a focused replacement covering the workflows you actually use.

This is not a plan for rebuilding the entire SaaS platform. It is a plan for migrating from a broad tool to a purpose-built system that covers your critical 10-20% of features, integrated directly with your existing systems. For the strategic rationale behind that approach, see our pillar guide to replacing SaaS with custom AI-built software.

Phase 1: Discovery (weeks 1-3)

Discovery is the most important phase. Everything that follows depends on what you learn here. The goal is simple: understand what your team actually does in the SaaS tool, not what the SaaS tool is capable of doing.

Workflow mapping

Start with observation, not with the SaaS vendor’s feature list. Sit with each team that uses the tool and document what they do day to day. Which screens do they visit? What data do they enter? What reports do they pull? What workarounds have they built because the tool does not fit their process?

This produces a workflow map that reflects reality. It is typically much narrower than the SaaS product’s full capability set. A CRM with 200 features might have 15 workflows that your team uses daily. Those 15 workflows are your build scope.

Data audit

Catalogue every data entity in the SaaS platform. Contacts, deals, activities, documents, custom fields, tags, notes, and any derived data (scores, analytics, calculated fields). For each entity, determine:

• Whether it needs to migrate to the new system
• Whether it can be archived (accessible but not actively used)
• Whether it can be discarded

The data audit also surfaces data quality issues. Duplicate records, orphaned relationships, incomplete entries, and inconsistent formatting are all common. Cleaning these during migration is cheaper than carrying them forward.

Integration mapping

Document every system that connects to the SaaS tool. This includes formal integrations (API connections, middleware, webhooks) and informal ones (CSV exports pasted into spreadsheets, manual data re-entry between systems). Informal integrations are often the most painful to miss.

Success criteria and stakeholder alignment

Define what “done” looks like before the build starts. Success criteria should be specific and measurable: “sales team can create, update, and close deals,” not “the system works.” Get sign-off from every stakeholder group that will use the new system.

Output: a functional specification and data migration plan. This document drives every subsequent phase.

Phase 2: Build (weeks 4-10)

The build phase turns the discovery output into working software. AI-augmented development compresses this timeline significantly compared with traditional approaches.

AI-augmented development

Tools like Cursor, Claude Code, and GitHub Copilot accelerate delivery by 40-50% compared with traditional development. This is not about generating code and hoping it works. It is about experienced developers using AI tools to eliminate boilerplate, accelerate testing, and focus their time on business-specific logic.

Sprint-based delivery with fortnightly demos keeps stakeholders engaged and catches misunderstandings early. Each demo should show working software, not slides. If a workflow does not match expectations, the next sprint corrects it.

Build only what you use

This is the discipline that separates a successful migration from a failed one. Build the workflows identified in discovery. Nothing more. If the SaaS tool had a reporting module your team never used, do not build a reporting module. If the SaaS tool had a marketing automation engine that nobody configured, leave it out.

The temptation to add “just one more feature” during the build is real and must be resisted. Every additional feature extends the timeline, delays parallel running, and increases the risk that the migration stalls.

Integrate, do not build, commodity capabilities

For capabilities that are not specific to your business, integrate specialist APIs:

• Email delivery: Postmark or SendGrid, not a custom email engine
• Payment processing: Stripe, not a custom payment gateway
• Document generation: a specialist API, not a custom PDF renderer
• Authentication: Azure AD B2C or Auth0, not a custom identity system

The custom system’s value is in the business-specific workflows and the direct integrations with your existing systems. Commodity infrastructure should be bought, not built.

Infrastructure setup

Infrastructure is provisioned in parallel with the application build. A typical stack includes Azure App Service or Azure Kubernetes Service (AKS), Azure SQL or Cosmos DB, Azure DevOps or GitHub Actions for CI/CD, and Application Insights for monitoring. Infrastructure as code (Bicep or Terraform) ensures that staging and production environments are identical.

Output: working software, deployed to staging, covering all workflows from the discovery specification.

Phase 3: Data migration (weeks 3-11, runs in parallel)

Data migration is the most underestimated workstream in SaaS replacement projects. It is not a weekend task. It is a distinct workstream that runs in parallel with the build, starting in week 3 and continuing through to the parallel running phase.

Export from SaaS

Most SaaS platforms offer data export via API or bulk download. The quality of these exports varies enormously. Some vendors provide clean, well-structured exports. Others provide partial data, proprietary formats, or rate-limited APIs that make bulk extraction slow and painful.

Run a test export early, during discovery if possible. This reveals the format, the gaps, and any commercial restrictions (some vendors charge for bulk exports above standard tiers). If the export is inadequate, negotiate with the vendor before you are under time pressure.

UK GDPR Article 20 provides a data portability right for personal data processed on the basis of consent or contract performance. This right requires data in a structured, machine-readable format. It does not cover derived data (analytics, scores, predictions) or non-personal business data. For a detailed treatment of portability rights, see our legal guide to replacing SaaS.

Transform to your new data model

The SaaS platform’s data model will not match your new system’s data model. Transformation is required. This includes:

• Schema mapping: which fields in the old system correspond to which fields in the new system
• Data type conversions: dates, currencies, enumerations, and custom field types
• Relationship reconstruction: rebuilding foreign key relationships between entities
• Data cleansing: deduplication, format standardisation, and completeness validation

Build the transformation as a repeatable, automated pipeline. You will run it multiple times: once for initial testing, once for parallel running, and once for the final cutover sync.

Handle edge cases

Every SaaS migration surfaces edge cases that the clean data model does not anticipate:

• Incomplete records where required fields are empty
• Orphaned relationships where a contact references a deal that no longer exists
• Custom fields with inconsistent data types (a field labelled “date” that contains free text)
• Historical data that predates a schema change in the SaaS platform
• Attachments and files that need separate handling from structured data

Document every edge case and the decision taken (migrate, transform, discard, or flag for manual review). This register becomes the audit trail for data integrity.

Validate and reconcile

After every migration run, reconcile. Compare record counts, spot-check individual records, and validate calculations. Involve the business stakeholders who know the data best. A data migration that is technically complete but contains incorrect records is worse than no migration at all.

Output: verified data in the new system, with a documented transformation pipeline and an edge case register.

Phase 4: Parallel running (weeks 11-12)

Parallel running is the phase most often skipped to “save time.” Skipping it is the single most common cause of migration failure. Both systems run simultaneously for two weeks, with your team using the new system for daily work while the SaaS product remains active as a safety net.

Why parallel running is non-negotiable

Staging environments do not replicate production conditions. Real users with real data and real time pressure will find issues that testing did not surface. A missing field in a report. A workflow step that made sense in a demo but breaks under production volume. A data migration gap where a record type was overlooked.

Parallel running catches these issues before the old system is decommissioned. The cost of running two systems for two weeks is trivial compared with the cost of a failed cutover.

Daily reconciliation

During parallel running, reconcile data between the two systems daily. New records created in the new system should be checked against the SaaS system’s equivalent. Discrepancies should be investigated and resolved the same day. This builds confidence that the new system is producing correct results.

Collect feedback and fix issues

Run a dedicated feedback channel (a Slack channel, a Teams group, or a simple shared spreadsheet) where users report issues, confusion, or missing functionality. Triage daily. Fix critical issues immediately. Defer cosmetic improvements to a post-cutover iteration.

Training

Schedule two to three half-day training sessions during the parallel running period. Focus on the differences between the old and new systems rather than teaching from scratch. The custom system is built around your existing workflows, so the conceptual model is familiar. Training covers the new interface, any workflow changes, and the reporting tools.

Output: team confidence and confirmed data accuracy. A clear go/no-go decision for cutover.

Phase 5: Cutover (week 13)

Cutover is a planned event, not a gradual transition. Pick a date, communicate it clearly, and execute against a documented runbook.

Timing

Avoid month-end, quarter-end, or peak business periods. The cutover introduces a short period of elevated risk, and that risk should not coincide with the moments when the business relies most heavily on its systems. A mid-month Monday is typically the safest choice.

Cutover runbook

The cutover should follow a step-by-step runbook that has been reviewed and rehearsed:

1. Final data sync from the SaaS platform, capturing any records created since the last migration run
2. Reconciliation check on the final sync, confirming completeness
3. Switch integrations to point at the new system (DNS changes, API endpoint updates, webhook reconfigurations)
4. Smoke test all critical workflows in production
5. Communicate go-live to all users
6. Begin hypercare monitoring

Hypercare support

For one to two weeks after cutover, provide heightened support. This means faster response times, a dedicated support channel, and a team member available to triage issues in real time. Most post-cutover issues are minor: a field label that is confusing, a report that needs a tweak, a workflow step that could be streamlined.

Rollback plan

The rollback plan must be documented and tested before cutover day. If the cutover reveals a critical issue that cannot be resolved quickly, the team reverts to the SaaS system. This is why the SaaS subscription stays active throughout the parallel running period and the rollback window.

The rollback window is typically one to two weeks after cutover. Only after that window passes with no critical issues should the SaaS subscription be cancelled.

SaaS decommissioning

After the rollback window closes:

• Export a final backup from the SaaS platform and archive it
• Cancel the subscription
• Update all documentation, training materials, and internal wikis
• Remove any middleware or integration code that referenced the old system

Output: production system live, SaaS subscription terminated, team operating on the new system.

What are the common mistakes to avoid?

These are the patterns we see in migrations that stall or fail:

• Trying to rebuild the entire SaaS feature set. The whole point of SaaS replacement is that you only need 10-20% of the features. Build what you use. If the vendor had 200 features and you use 15, build 15.
• Treating data migration as an afterthought. Data migration is a distinct workstream that starts in week 3 and runs through to cutover. It needs its own plan, its own testing, and its own stakeholder validation.
• Skipping parallel running to save time. Two weeks of parallel running costs far less than a failed cutover. This phase is where you discover the issues that staging testing missed.
• Cutting over during a peak period. Month-end, quarter-end, and annual reporting periods are not the time to introduce a new system. Plan around your business calendar.
• Cancelling the SaaS subscription before confirming the new system works. Keep the SaaS active through the rollback window. The cost of an extra month’s subscription is negligible compared with the cost of having no fallback.
• Underestimating change management. The technical migration might be flawless, but if users are not trained and engaged, adoption will suffer. Involve users from discovery through to cutover.

What about the legal side?

SaaS replacement raises questions about intellectual property, terms of service, and data portability. The short answer: UK copyright law protects how software is written, not what it does. You can legally build a product that replicates SaaS functionality, provided you use clean-room implementation and do not copy source code or distinctive design.

For a detailed treatment of the case law, clean-room process, and data portability rights, see our legal guide to replacing SaaS with custom software. For the IP implications of AI-generated code specifically, see who owns AI-written code.

Where to go from here

This playbook gives you the week-by-week structure. The broader strategic framework, including the economic analysis, decision criteria, and worked examples, is covered in our pillar guide to replacing SaaS with custom AI-built software.

If you are ready to start planning a migration, or if you want to evaluate whether replacement makes sense for your specific SaaS tool, we can help. Our SaaS replacement assessments are free, honest, and obligation-free. If SaaS is the right answer for your situation, we will tell you.

For additional context on specific replacement scenarios, see Replace HubSpot with a Custom AI-Built CRM and our guide on when to replace SaaS with custom software.

Book a consultation