SaaS Replacement Migration Plan: Data, Permissions, Rollback, and Handover

This guide starts after the first decision: you have found a rented product that may be worth replacing. If you are still deciding whether ownership makes sense, start with the practical guide to SaaS replacement, then put the hard savings and transition costs into the three-year economics.

When should you stop before the migration starts?

Some replacements should end during planning. That is a good outcome. A short investigation is cheaper than discovering six months later that the old product was holding together more of the business than anyone knew.

Keep renting when the workflow is ordinary, the subscription is inexpensive, and the current product works. Keep renting when the provider carries a burden you should not take on yourself, including payroll, the general ledger, cloud infrastructure, and security tooling. A company should also stop when it cannot name a person who will own the replacement after launch.

Data can stop the project too. If the vendor cannot provide a usable export, important records live only in attachments or free-form notes, or nobody can explain which history must be preserved, the migration risk may exceed the savings. That does not always mean staying forever. It means the data problem must be understood and priced before the build is approved.

There is one more reason to wait: timing. A renewal date can fund the work, but it should not force a cutover during payroll, month-end close, peak season, or a regulatory filing. Missing one renewal is painful. Interrupting the business is worse.

Decide what “done” means before anyone builds

The safest migration begins with a short written agreement about what must be true before the old product can be turned off. This is not a long specification. It is a list of observable checks that the operator, the builder, and the person approving the cutover all understand.

For a field-service system, the list might include:

• Dispatch can assign and reassign every active job.
• A technician can see the customer, address, work order, and parts from a phone.
• Completed work creates the correct invoice and audit history.
• Finance can reconcile a day in the new system to the same day in the old one.
• Current customers, open jobs, inventory, price lists, documents, and user permissions have moved.
• The company can restore a backup and reach the person responsible for an incident.

Write down what is intentionally not moving as well. Old test records, abandoned custom fields, duplicate contacts, and years of useless activity logs can make a migration larger without making it safer. Legal, tax, contractual, and operational retention requirements decide what must stay. Habit should not.

This is also the point to identify every connection to the old product. Imports, exports, scheduled reports, payment feeds, single sign-on, email notifications, web forms, and spreadsheets maintained by one experienced employee can all be part of the real workflow. The replacement is not ready because its screens look right. It is ready when the work that enters and leaves those screens still works.

Treat the data migration as its own piece of work

Data migration is not a final upload performed the night before launch. It should begin early enough to reveal bad assumptions while they are still cheap to fix.

1. Preserve the source

Take a complete export and keep an unchanged copy before transforming anything. Record when it was created, what it contains, what it excludes, and how it can be opened later. Attachments and documents often need a separate export from the rows that refer to them.

The company should hold this copy in an account it controls. A file on the builder's laptop is not a backup.

2. Map meaning, not just columns

A field called “status” may mean something different in two products. A customer may be one row in the old tool but several related records in the new one. Decide how every required field, relationship, attachment, and identifier moves, and record which source value produced which new value.

Keep the old identifiers in the new database when practical. They make reconciliation and support much easier because a person can trace a questionable record back to its source.

3. Rehearse with real data

Run the migration before launch, preferably more than once. A rehearsal reveals invalid dates, missing attachments, duplicate customers, unexpected field lengths, and records that do not fit the new rules. It also tells you how long the real move will take.

Microsoft's current migration guidance recommends a full migration followed by smaller “delta” loads when production volume makes a single move too long. That approach gives users time to compare the source and target before the final switch. Read Microsoft's data migration planning guidance.

4. Reconcile the business, not only the database

Matching record counts is necessary, but it is not enough. Ten thousand invoices can move while their totals, taxes, customer links, or attached documents are wrong. Reconcile the measures the business already trusts: open invoice value, active customer count, jobs by status, inventory by location, or another small set of totals that should match on both sides.

Then sample the awkward cases. Find the customer with three locations, the partially paid invoice, the job reopened twice, the user with two roles, and the document uploaded five years ago. Clean rows rarely expose the problem.

5. Move the final changes

Between the rehearsal and launch, people will keep using the old product. The plan needs a final move for those new and changed records. Depending on the workflow, that may require a short period when nobody can make changes, or a final delta load immediately before users enter the replacement.

Never leave this rule implicit. If a salesperson can update the old CRM while an operator updates the new one, the company now has two different histories and no simple way to know which is right.

Rebuild permissions deliberately

Permissions are part of the migration, not a setting to revisit after launch. Start with a simple table showing each role and the actions it needs: view, create, edit, approve, export, delete, and administer. Include employees, customers, contractors, integrations, and automated jobs.

Do not copy broad administrator access just because it is easier. OWASP recommends granting the minimum access needed, denying access by default, checking permission on every request, and logging authorization events. Those principles matter in plain business terms: a dispatcher should not see payroll, a customer should not see another customer's jobs, and an integration should not be able to delete records when it only needs to read them. Read OWASP's authorization guidance.

The checks before launch should include:

• Every role can complete the work it is supposed to do.
• Every role is blocked from work and information it should not reach.
• Departed employees and old vendor accounts have no access.
• Automated connections use their own credentials rather than a person's login.
• Changes to permissions, exports, deletions, and important approvals are recorded.
• Someone is responsible for reviewing access after roles or employment change.

Logs need an owner too. OWASP's logging guidance recommends consistent event records, restricted access to the logs, and monitoring that alerts the responsible team when serious events happen. A pile of events nobody reviews is storage, not oversight. Read OWASP's application logging guidance.

Run both systems without creating two versions of the truth

Parallel running means the old and new systems stay available while the company proves the replacement. It reduces risk, but only if everyone knows which system is allowed to accept new information.

For many workflow replacements, the cleanest pattern is:

1. Move the current data into the replacement.
2. Let a small group perform real work and reconcile the result.
3. Move the remaining changes from the old product.
4. Make the replacement the only place for new work.
5. Keep the old product available as a read-only reference during the rollback window.

Writing to both systems can be necessary when downtime is unacceptable, but it adds real engineering work. Every new record and correction must reach both places, and the team needs a rule for resolving conflicts. Do not promise “zero downtime” until someone has priced that complexity.

The length of parallel running should follow the business cycle. A reporting tool may need to survive a full month-end. A dispatch tool may need several ordinary days plus one busy day. A seasonal workflow may not be proven until the season arrives. Calendar time alone is a poor acceptance test.

Write the rollback plan before cutover

Cutover is the moment users stop working in the old product and start working in the replacement. A rollback plan says how the company returns to the old product if the replacement fails an important check.

AWS recommends defining the checkpoints that trigger rollback, how data will be handled, and the person who decides whether to repair the new system or return to the old one. Its guidance also draws an important line between rolling back before new information has entered the replacement and rolling back afterward. Once new orders, payments, or customer changes exist only in the new system, returning to the old one requires a plan for moving those changes back. Read AWS's cutover and rollback guidance.

A useful rollback plan fits on one page and answers six questions:

1. What exact failures trigger a rollback?
2. Who makes the decision?
3. How long does that person have to decide?
4. How are users redirected to the old product?
5. What happens to information created in the replacement after cutover?
6. Who tells employees, customers, and partners what changed?

Rehearse it. A backup that has never been restored is a hope. A rollback document that nobody has followed is the same.

Do not cancel the old subscription on launch day. Keep it through the agreed rollback window, preserve a final export, confirm retention duties, then revoke connections and user access deliberately. The cancellation date should be in the plan from the start because it determines when the savings actually begin.

Make handover a test, not a folder of documents

Handover is complete when the company can operate the replacement without the original builder holding a key nobody else has. Documentation helps, but ownership is demonstrated by what another qualified person can do.

The company should control:

• The source-code repository and its billing.
• The cloud account, database, storage, domain, and email services.
• Secrets and credentials in a company-controlled password or secret manager.
• Production monitoring, error alerts, backups, and restore access.
• Vendor contracts, licenses, and renewal notices.
• The design files, operating instructions, and decision history needed for future changes.

Access should be based on role. GitHub, for example, separates read, write, maintenance, and administrative repository access so a contributor does not need the power to change security settings or delete the repository. Read GitHub's repository role guidance.

Before final handover, ask someone other than the lead builder to perform four tasks:

1. Deploy a small change.
2. Restore a backup into a safe environment.
3. Find the cause of a simulated failure using the logs.
4. Remove the builder's access without taking the system down.

If those tasks cannot be completed, the company may own the contract but still depend on the provider.

Decide who maintains the replacement

Owned software still has bills and chores. Hosting, monitoring, backups, security updates, bug fixes, user support, and small changes belong in the financial case from the beginning. The SaaS replacement economics model keeps those costs separate from the license savings so the comparison does not pretend maintenance is free.

There are three workable maintenance arrangements:

• An internal employee or team. Best when the system is central enough to need frequent changes and the company already has technical leadership.
• The original builder under a clear support agreement. Useful when the company wants continuity, provided the code and accounts remain under company control and another team can take over.
• Another qualified provider. A practical test of whether handover was real. The new provider should be able to understand, deploy, monitor, and change the system from the delivered materials.

Whichever arrangement you choose, name one person inside the company as the accountable owner. That person does not have to write code. They decide priorities, approve access, know what support costs, and make sure incidents reach someone who can act.

A sensible monthly operating review is short: uptime and serious errors, failed jobs and integrations, backup status, security updates, access changes, support requests, maintenance spend, and the next small improvements. The goal is not a committee. It is to keep small problems from becoming a new reason to feel trapped.

What defensible proof looks like

The provider should show more than attractive screens. Ask for a migration runbook, a permission table, acceptance checks, a rollback plan, the company-owned accounts, and a named maintenance arrangement. Ask who performed the last restore test and whether another engineer has deployed the system.

Runpoint replaced ServiceTitan and BuildOps for Smith Mechanical with an owned field-service platform covering dispatch, technician work, CRM, inventory, fleet, time, reporting, invoicing, payment reconciliation, and a customer portal. Smith Mechanical approved publication of the project facts, and the fixed-fee replacement reduced license costs by $200,000 in the first twelve months. Read the Smith Mechanical case study.

That case supports the economics and the scope of an owned replacement. It does not prove that every migration is safe or that every subscription should be rebuilt. The plan above still has to be written for each company's data, users, renewal dates, and tolerance for interruption.

The migration plan to ask for

Before approving a SaaS replacement, ask the provider to put these items in one place:

• The workflows and records that must move, plus what will stay behind.
• The acceptance checks that decide whether the replacement is ready.
• The source export, field mapping, rehearsal, final sync, and reconciliation plan.
• The user, customer, administrator, and integration permission table.
• The parallel-running rule and the single place where new work will be entered.
• The rollback triggers, decision owner, time limit, and treatment of new data.
• The company-owned code, accounts, credentials, backups, monitoring, and documentation.
• The internal owner, support arrangement, expected maintenance cost, and exit path from the builder.
• The final export, access removal, and old-subscription cancellation date.

If a proposal cannot answer those questions, the savings estimate is not ready to trust. If you want the category definition and the test for what to keep renting, read SaaS Replacement: What It Is, When It Pays, and What Not to Replace. If you already have the contracts and renewal dates, request the free Operating Stack ROI Audit and we will help you decide which one, if any, is worth replacing first.

Frequently asked questions

How do you migrate data out of a SaaS product safely? Export and preserve the source data first, map every required field and relationship, rehearse the migration, reconcile business totals as well as record counts, then move only the changes made since the rehearsal. Keep the old product available until the new system passes its agreed checks.

Should the old and new systems run at the same time? Usually, but parallel running needs a clear rule about where new information is entered. Letting people update both systems creates two conflicting versions of the truth. A safer pattern is often to keep the old product available for reference while the new system becomes the only place for new work.

What belongs in a SaaS migration rollback plan? Name the conditions that trigger a rollback, the person who makes the call, the deadline for that decision, the steps for redirecting users, and the method for preserving any information created after cutover. Test the plan before launch.

Who maintains custom software after handover? A named owner inside the company should be accountable for priorities, access, and vendor decisions. Day-to-day technical work can be handled by an employee, the original builder, or another qualified team, but the company should own the code, cloud accounts, data, documentation, and the right to change providers.

When should a company not replace SaaS? Do not replace a product when the workflow is ordinary, the subscription is inexpensive, the current product works, clean data extraction is impossible, nobody will own the new system, or a mistake could interrupt payroll, accounting, security, or another critical commodity service.