Don't port your legacy app. Rebuild it on purpose.

Most legacy rebuilds go wrong before a line of new code is written. Nobody knows how big the old app really is, and the new one is argued about in the abstract. AI changes the economics of a rebuild, but only for teams that plan first, build a delivery factory second and choose tooling last.

The case against a rewrite

The strongest argument against everything that follows is 26 years old. In 2000, Joel Spolsky called Netscape's decision to rewrite its browser from scratch "the single worst strategic mistake that any software company can make". His reasoning still holds: old code has been used and tested, and the ugly bits are usually bug fixes. Throw the code away and you throw away that knowledge.

The modern alternative is Martin Fowler's strangler fig: build new components alongside the legacy system and move behaviour across gradually, seam by seam. If your problem is the code itself - untested, slow to change, stuck on an old runtime - strangle it. It is lower risk and the business never stops.

Our view is that the strangler fig is the right default and the wrong answer for one specific class of platform. When the problem is the product model rather than the code, an incremental migration faithfully preserves the wrong model. If tenancy, identity and the data model are wrong, every strangled component inherits them. That is when a rebuild earns its risk.

AI has also changed Spolsky's maths in one important way. The knowledge buried in old code is no longer lost when you rewrite, because agents can extract it first.

Age is not the problem. Shape is.

We recently sat down with the leadership of a vertical SaaS business running a 20-year-old PHP platform: around half a million lines of code, more than 100 screens, hundreds of tenants and no automated tests. Their CTO put it well. The age of the platform is not the problem; the way it was built is.

The symptoms will be familiar to anyone who has run a long-lived B2B platform:

• An entity-attribute-value data model on a relational database: endlessly flexible, painfully slow and hard to reason about.
• Identity owned by each tenant, so a worker serving five customers needs five logins, which rules out a decent mobile experience.
• Customer-specific behaviour hard-coded as if statements rather than configuration or feature flags. Support staff say it feels like supporting hundreds of different products.
• Configurability so deep that onboarding a single customer takes 12 weeks.
• An unsupported runtime, which turns every newly disclosed vulnerability into a fire drill.

The team is already using AI. But AI on a poor foundation produces more of the same problems, faster. Coding agents amplify whatever architecture they are pointed at, and with no test suite, nothing tells them they are wrong.

The internal estimate was three to six months of planning and around 12 months of build. The investors wanted both compressed into a fraction of that, without more capital. Neither position could be tested, because nobody knew how big the platform really was. That is the first problem to solve.

1. Map the app with agents before anyone quotes a number

Every rebuild estimate we see is either top-down (what the board can afford) or bottom-up from a screen count. Both are guesses. Screen counts are especially misleading in older apps, where developers designed the UX and one screen can hide five workflows.

We now start with a "plan for the plan": a short diagnostic in which agents build a product graph of what actually exists. They work from three sources:

• Code. Agents read the codebase to identify modules, features, the data model, integrations and tenant-specific branches, and separate the business logic from the UI.
• Knowledge. Jira, Confluence, support tickets and defect history capture intent and known issues that the code does not explain.
• Product. A navigation agent logs into a test environment and drives the running app, exercising screens, pathways and edge cases to validate what the code analysis inferred.

The outputs are linked into a single graph of modules, features, screens, workflows, data entities, integrations and customisation hotspots. On a current rebuild of a client-server product as cloud SaaS, our navigation agent ran for around 36 hours across the application. It gave the team a first cut of current-state requirements to work from before discovery began.

This is worth doing for two reasons. First, it lets you size the rebuild against real delivery data rather than opinion. We compare the graph with rebuilds we are delivering now, so the question becomes "is this half the size of that one, or twice?" Second, it is a head start on discovery, not a substitute for it. The graph tells you what exists and where complexity concentrates. It does not tell you what the new product should be.

The inputs are modest: read access to the code, a test environment with de-identified data across a sample of tenant configurations, logins for each user role, and access to Jira and Confluence. No production data is needed.

2. Split the admin screens from the product

In most business apps, a large share of the surface is administration: settings, reference data, user management, lookups and configuration. On the client-server rebuild we are delivering now, about a third of the app is admin screens that will come across largely as they are.

Treat that third as a different class of work. It needs accurate requirements and consistent patterns, not design invention. That makes it ideal for spec-driven generation: extract the current behaviour with agents, write the spec, and let the factory build it to a standard pattern with minimal design time.

The temptation is to start building the admin screens first, to show the board progress. Resist it. Admin screens sit on top of data model, identity and tenancy decisions you have not made yet, and they will be rebuilt if those decisions change. Use the split to accelerate analysis and to free your scarce senior people for the core workflows, where the product is won or lost.

3. Decide what changes and what stays

A rebuild is a chance to rethink the product, not just the stack. But "rethink everything" is how a 12-month rebuild becomes a 30-month one. Be explicit, capability by capability, about which of four treatments each one gets:

• Carry across: same behaviour, new stack, standard patterns. Typical examples: admin, reference data, fixed-format reports.
• Redesign: same job, new workflow and UX. Typical examples: core flows that developers designed years ago.
• Re-architect: foundational decisions change. Typical examples: identity, tenancy, data model, integrations.
• Retire: not rebuilt. Typical examples: unused features, workarounds for old limits.

Watch for two traps. First, the old code is the only complete specification, including the bugs customers now rely on as features. The behaviour is deterministic, but no human knows which tenant gets which behaviour until an agent traces it.

Second, the biggest change is often philosophical: moving from an unopinionated product to an opinionated one. After 20 years you have the data to know how your customers actually operate. A rebuild that keeps every configuration option also keeps the 12-week onboarding. Encode best practice as the default and make configuration the exception.

4. Separate platform from bespoke

Hard-coded customer branches are the most expensive thing in a legacy SaaS codebase, and the most politically sensitive. Customers often paid for those customisations, so you cannot simply delete them.

Our approach:

1. Use the product graph to find the customisation hotspots: where tenant-specific branches concentrate, and how many tenants each one affects.
2. Design the platform to cover around 80% of customers with no bespoke code at all.
3. Where three customers have three variations of the same behaviour, abstract them into one configurable capability driven by settings or feature flags.
4. Ring-fence the true exceptions and deal with them later, as an extension point or a commercial conversation, never a fork.

Platform decisions also unlock products the old architecture made impossible. Centralised identity is what lets a worker who serves several organisations use one login and one mobile app. That is a platform capability, designed once, not per tenant.

The rule we push clients towards: every customer-specific branch is a business-model decision disguised as code. Make it in the open, with a price on it.

The top-right quadrant is the product your customers will judge you on. The bottom-right is where the factory earns its keep.

5. Plan the app, then build the factory, then choose the tooling

The order matters, and most teams get it backwards. They pick an AI coding tool, point it at a backlog and hope.

Plan the app. Decide what kind of product you are building before anything else: how tenancy works, web or mobile-first, how opinionated it is, what compliance and audit obligations it carries, and what the quality bar is. These are human decisions. The agents' map informs them; it does not make them.

Build the factory. The factory is the system that turns specs into tested, secure code, repeatedly. Ours is built on spec-driven development, the core of what we call the AI PDLC. Product specs, a technical plan and acceptance tests are written first. Agents then build overnight and loop until the tests pass. Deterministic pipeline checks for security, privacy and code quality sit around the agents, so nothing ships on a model's say-so. A rebuild is the cheapest moment to put these foundations in; retrofitting them into a legacy codebase is far harder.

Choose the tooling. Only then pick the models, agent harness, CI gates and observability that suit the factory. Tooling chosen first constrains the factory to whatever that tool happens to do well.

On a recent trip to San Francisco, I deliberately skipped the most fashionable companies and spent time with businesses doing unglamorous software development very well, including "dark factory" set-ups where agents code through the night. Two questions decide whether that works:

• Are you building the right thing? The planning answers that.
• Are you burning tokens for nothing? The factory answers that. Good specs and tests stop agents looping on ambiguity.

Get the plan and the factory right and the overnight build is a multiplier. Get them wrong and it is an expensive way to build the wrong product faster.

One second-order effect is easy to miss. Teams rebuilding legacy platforms are often relatively junior, or will be mostly new hires. A well-built factory encodes your standards in specs, skills and pipelines, so it doubles as the way you onboard and upskill the team.

What to tell your board

Boards and private equity owners want the rebuild faster and cheaper. Both are possible up to a point, but speed costs capital, and nobody can honestly commit to a number for a platform nobody has measured.

What you can commit to is a sequence in which uncertainty falls at every step:

1. Diagnostic, about a week: map the platform with agents and size it against comparable delivery data.
2. Discovery, measured in weeks and accelerated by the same agents: elaborate current-state requirements feature by feature, decide what changes and what stays, and design the target architecture.
3. Factory set-up, in parallel with discovery: specs, skills, pipelines and team upskilling.
4. Build: the phase with the most variability, estimated on evidence once the first three are done.

The first three can be planned and priced with confidence today. The build cannot, and anyone who quotes it before mapping the platform is guessing. Rather than arguing over whose guess is right, give the board an empirical basis within weeks and a clear decision point when it lands.

Where we fit

We learned much of this at MYOB, taking desktop products online, and have spent the past six years rebuilding desktop and client-server products as cloud SaaS for clients. Propel combines product strategy, AI engineering and delivery in one team, and we now run the agentic mapping, spec-driven factory and AI PDLC described here on live rebuilds.

If you are sitting on an ageing PHP, desktop or client-server platform and weighing a rebuild, start with the plan for the plan. Book a time with me and we can work out what yours would take.

Sources

• Joel Spolsky, Things You Should Never Do, Part I, April 2000
• Martin Fowler, Strangler Fig Application