Modernize your SaaS without a rebuild

Chapter 1

The 10-minute check: rebuild or not?

Most products that feel like they need a rebuild don't. The pain usually sits in a few parts, and those can be replaced while everything else keeps running. Tick every statement that is true of your product today:

Reading your result

• A stop sign ticked (no security fixes, or an end-of-life version): deal with that first. Code that can't get security fixes has to be upgraded or replaced before anything else. The module sheet shows whether that means a few modules or the whole product.
• More rebuild signs than keep signs: fill in the module sheet. If the rebuild signs sit in one or two modules, rebuild those, not the product. If they are everywhere, read chapter 9.
• As many keep signs as rebuild signs, or more: keep and fix, in stages. Mark any module with a rebuild sign in the sheet.

If you lean towards a rebuild, one more question: is the product small enough to rebuild in under two quarters? If not, replacing it in stages is usually safer.

Now do it one module at a time

Fill in this sheet with your lead developer. It turns “the whole thing is a mess” into a list you can act on, and it is the most useful thing to bring to any first call with an outside team.

Keep, fix or rebuild: one line per module
Product:	Filled in by:	Date:

Module	Keep / Fix / Rebuild	Why	Pain (1-5)	Changes often? (Y/N)	Risk if it breaks (L/M/H)
Sign-up and login
Billing



First module to work on, and why:
What we will not touch this year:

Chapter 2

Map what you run, then pick the first module

You can't plan changes to something nobody has written down. Before deciding anything, list:

• Apps and services: everything that runs, including background jobs and scheduled tasks.
• Data: each database and file store, its size, and what lives in it.
• Integrations: payments, email, CRMs, partner feeds, and what breaks if each one fails.
• Who uses what: customer-facing parts versus internal tools.
• Where it runs: hosting, regions, and what it costs each month.
• Regulated data: health, payment or personal data, and which rules apply to it.
• How releases happen today: who deploys, how often, and how a bad release is undone.
• Recent incidents: the last five things that broke, and why.

Pick the first module

Use the pain, change and risk columns from your sheet. Start where pain is high, the code changes often, and a failure would be noticed but not fatal. Leave the riskiest parts, usually billing and login, until the team has a rhythm.

Don't start with the hardest part. The first module teaches everyone how the work runs: how releases go, how rollback works, who decides. Learn that on something that can't take the business down.

Chapter 3

Five stages, while it stays live

Each stage ends with a working product. You can stop after any of them. The “Done when” line under each one is how you know it is finished.

1. 1

   Assess

   The map from chapter 2, a keep, fix or rebuild sheet, an agreed order of work, and a baseline: page speed, error rate and how often you release, so later stages can be measured.

   Done when: Everyone who signs off agrees the order, and the baseline is written down.

2. 2

   Stabilize

   Automated tests on the journeys that make money, automatic checks on every change, error alerts, and a private copy of the app (staging) to try changes first.

   Done when: Tests cover the journeys that make money, every change runs them, and errors reach a named person before customers notice.

3. 3

   Replace, one module at a time

   The new version of a module runs beside the old one. Users move across in steps. Then, after an agreed period with no mismatches, the old one is switched off. Engineers call this the strangler pattern.

   Done when: The old module is switched off, and nothing that relied on it broke.

4. 4

   Speed and interface

   The slow pages and dated screens your users complain about, fixed and measured against how they were before.

   Done when: The baseline numbers from stage 1 have moved.

5. 5

   AI, if it earns its place

   Only once the base is stable: features that save your users or your team real time. If it touches patient data, the AI provider needs a BAA (Business Associate Agreement) too.

   Done when: It pays for itself in time or money, measured.

An example: replacing a reports module

Illustrative, not a client project

1. Build the new reports alongside the old ones, reading the same data.
2. Turn them on for your own team first, behind a feature flag: a switch that turns a feature on for chosen users only.
3. Compare old and new totals every day until they match.
4. Move customers across in steps: a few, then a quarter, then everyone.
5. Once totals have matched for an agreed period, switch the old reports off and delete their code.

What decides how long each stage takes, and what it costs

• The size of the code, and how much of it is covered by tests today. A product with no tests costs more to change safely, because the tests come first.
• The number of integrations, and how fragile they are.
• Regulated data, and the approvals it needs.
• How much your own team can take on alongside their day jobs.

Making the case to your board

Put two things side by side:

• The cost of doing nothing: developer hours spent on fixes and firefighting, features you can't ship, customers lost to slowness or outages, and the security exposure.
• What you will measure: how often you release, how long a change takes to go live, error rate, page speed, hosting cost and hours spent on incidents. Take the baseline in stage 1, and report the same numbers after each stage.

Chapter 4

Keeping it live while it changes

Five things go wrong when live products change. Each has a standard technique:

Write the rollback plan before each stage starts

Decide what triggers a rollback, and who calls it, while everyone is calm. Fill this in for every stage:

Rollback plan: one per stage

Stage:
What we are changing:
Roll back if:	For example: errors above normal for 10 minutes, or failed payments above the normal rate
Who decides:	One named person
How we roll back:	For example: switch the flag off, and send traffic back to the old module
Data written since the change:	How we keep it, or bring it back
How long it takes:
Who is on call, on each side:
How we tell customers, if needed:

Want a second opinion on your keep, fix or rebuild sheet? Tell us what you run today, and we will say plainly what to keep, fix or rebuild.

Chapter 5

Moving data without downtime

Data is where upgrades go wrong for customers. Code can be rolled back in minutes; lost or mismatched data can't. The safe pattern:

1. Change the database in steps, not in one go. Add the new column or table first, move the code across, and only then remove the old one. Old and new code both keep working throughout.
2. Keep one system as the source of truth. The old one stays in charge until the switch.
3. First, start copying every new change across to the new system, so nothing written during the move is missed.
4. Then copy the existing data across in small batches, in the background. The batch copy must never overwrite a record that has changed since, and small batches keep the live product from slowing down.
5. Check that the two match: record counts, totals and spot checks of real records. Fix any drift before going further.
6. Rehearse the switch on an anonymized, production-sized copy of the data (de-identified, for patient records), in a controlled environment, and time it.
7. Switch, and keep the old system in step: copy changes back to it until the new system has run cleanly for an agreed period, so you can switch back without losing data.
8. Write a cutover runbook: the steps, a named owner, a time window and a go or no-go check before you start.

Chapter 6

Risk, sign-off and access during the work

Keep one risk register for the whole project. Every risk has an owner and a trigger, so nobody has to improvise. Review it every week, at the status update. The rows below are examples:

Who signs off

Each stage starts only when its owner on your side signs off the plan and the rollback plan, and ends only when they sign off the result.

Access while outsiders are in your systems

• Production access only for named people, only for as long as a stage needs it.
• Outside accounts use two-factor login, or your own single sign-on.
• Every action in production logged, and the logs kept for your retention period.
• No one outside your company gets any access to systems holding patient records, even read-only, until a BAA is signed (in the US).
• A written emergency-access procedure: who can use it, and how its use is logged and reviewed.
• No copies of production data on laptops. Test with anonymized data, de-identified for patient records.
• Access removed, and passwords and keys changed, at the end of each stage and whenever someone leaves.
• Changes to security settings reviewed by someone on your side.

Chapter 7

Working alongside your own team

Most modernizations are shared between your developers and an outside team. Agree who does what before the first line of code:

No lock-in. If the outside team left tomorrow, your developers should be able to carry on from the code, the notes and the handover sessions alone.

Chapter 8

What a codebase assessment should tell you

Before you commit to any plan, from any team, ask for a written assessment. Use this list to judge it, ours included:

• A keep, fix or rebuild verdict for each module, with the reason.
• The riskiest areas, ranked.
• How releases happen today, and how much is covered by tests.
• Security issues found, by severity.
• Outdated frameworks and libraries, and the upgrade path for each.
• What hosting costs, and the quick savings.
• A staged plan: the order of work and what each stage delivers.
• What they did not look at.

Red flags

• A verdict before anyone has seen the code.
• “Everything needs rebuilding.”
• No written report, only a sales call.

Chapter 9

When to rebuild anyway, and how to do it safely

If chapter 1 pointed to a rebuild, the rules that keep an upgrade safe still apply. Rebuilds fail when they try to replace everything on one launch day.

• Rebuild in stages too. Run the new product beside the old one and move customers across in groups, not on one launch day.
• Freeze new features on the old product, or the rebuild chases a moving target.
• Move the data early and often, not at the end.
• Keep the old product running until the last customer has moved and stayed.

Quick answers

Questions teams ask

About Provis