How to Modernise Legacy SaaS Software Using AI-Assisted Development

Legacy SaaS is software that the business still sells or still runs, and that the current team is afraid to change. The login works. The invoices go out. The person who knew why a particular rule exists left three years ago. Modernisation is the work of making that system changeable again without stopping the company.

AI-assisted development changes the speed of some of the typing. It does not remove the need to understand the product.

Why teams modernise

The trigger is rarely “we prefer a newer framework”. It is one of these:

• Releases take weeks because every change risks an unrelated feature.
• The framework or runtime is out of support, and security patches are no longer routine.
• New customer requests need integrations the old architecture makes expensive.
• Hiring is hard because the stack is one nobody wants to learn.
• Reporting is a set of spreadsheets exported from the product, because the product cannot answer the question.
• A buyer, an auditor or a larger customer has asked questions about security and privacy that the system cannot answer cleanly.

A new interface, on its own, is not modernisation. If the database rules and the integrations stay opaque, you have reskinned the risk.

Rebuild, refactor, or move in slices

The default we recommend is incremental. Put a boundary around one workflow, build the new version of that workflow, migrate its data, and run it in production while the rest of the old system stays. A full rewrite is justified when the old code cannot be bounded, or when you are deliberately retiring behaviour rather than preserving it.

GoNow Luma is our own product, built as a platform rather than rescued from a client’s legacy codebase. It is evidence that we design and ship software. It is not evidence that a stranger’s SaaS can be replaced in the same way, or on the same timetable.

Where AI-assisted coding actually helps

Used by someone who can read the result, an assistant is useful for:

• Drafting boilerplate around a specification you wrote: forms, API clients, CRUD screens, typed models.
• Proposing tests for behaviour you have already described, including the edge cases you remembered to mention.
• Explaining an unfamiliar module so a human can confirm the explanation against the code.
• Repetitive refactors: renaming, extracting a function, converting a pattern that is already consistent.
• First drafts of migration scripts, which a human then runs against a copy of the data.

It is a poor sole author of:

• Pricing, permissions, billing and anything that moves money or personal data.
• Undocumented business rules. The model will invent a plausible rule. Plausible is not the same as true.
• Architecture. It will happily propose three incompatible structures in one afternoon.
• A “complete rewrite” from a zip file of the old repository. The output compiles more often than it behaves.

The productive pattern is a senior developer stating the constraint, reviewing the diff and refusing the parts that are only fluent. The unproductive pattern is pasting the repository into a chat window and asking for the new product.

Understand what the system actually does

Before choosing a target architecture, write down the behaviour. Source code is one input. It is not the whole input.

• Talk to the people who use it every day. Ask what they work around.
• Read support tickets and the billing exceptions. The edge cases live there.
• List the roles and what each role is allowed to see and change.
• List the jobs that run when nobody is looking: invoices, imports, emails, webhooks, nightly recalculations.
• Identify the reports that customers or accountants rely on. Those are requirements, even if they look like an export button.

If you cannot describe a workflow without opening the code, you are not ready to replace it. You are ready to investigate it.

Reverse-engineering without fooling yourself

For a system with little documentation, the reliable method is boring:

1. Pick one business outcome, such as “a manager creates a customer and the customer receives an invite”.
2. Click through it on a staging copy and record every state the screen can be in.
3. Trace that path in the code and the database.
4. Write the rule in a sentence a colleague can correct. “An invite expires after 14 days” is a requirement. “The user table has a token column” is an implementation detail.
5. Repeat for the workflows that earn or protect revenue. Leave the long tail until those are safe.

AI tools can narrate a file while you do this. Check the narration against the code. Where the code and the operators disagree, the operators are often describing a bug that has become a process. Decide explicitly whether the new system will keep the bug.

A roadmap you could stop

A useful roadmap has phases that each leave the business in a state you could stop in.

1. Map. Workflows, data, integrations, risks. A written decision on rebuild versus slices.
2. Make it safe to change. Version control, a staging environment, backups you have restored once, and enough tests around the workflows you are about to touch. If none of that exists, it is the first project.
3. Prototype the risky slice. The workflow everyone cites as the reason a rewrite is impossible. A prototype proves the approach. It is not the migration.
4. Replace that slice in production. One path, monitored, with a way back.
5. Repeat. The next slice starts when the last one is stable, not when a slide says so.

Dates belong on the slice in front of you. A single date for “the new platform” is a wish.

Data and databases

Most modernisation projects fail in the data, not in the interface.

• Inventory tables, who writes them, and which columns nobody can explain.
• Decide what is source of truth during the overlap. Two applications writing the same customer record will drift.
• Migrate with a repeatable script against a copy. Then again. The first run is a discovery exercise.
• Keep identifiers stable where external systems store them.
• Plan for history: invoices, audit logs and records you are legally required to retain. “We will start fresh” is often unacceptable to customers, and sometimes unlawful.
• Take a backup you have proved you can restore before the first production write.

PostgreSQL is a common, sound choice for new application data. It is not a reason to discard a database that is well understood and still fit. Move the data model when the model is the problem.

Security and privacy

A rewrite is a moment when old shortcuts become new incidents.

• Map personal data and why you hold it. In the UK and the EU that includes a lawful basis, retention, and a way to honour access and deletion requests. This consultancy operates from Spain. Your product may have its own duties. Get advice for the jurisdictions you serve rather than copying a blog checklist.
• Replace homemade password storage and homemade session logic with a maintained approach.
• Review third-party processors, including any AI provider whose API receives customer content. Do not paste production personal data into a prompt because it was convenient.
• Secrets stay out of the repository and out of the chat transcript used to generate a function.
• Log access to sensitive records. If the old system had an audit trail, the new one needs an equivalent before you switch.

AI-generated authentication code is a frequent source of confident mistakes. Treat it as a draft and prefer a library that is already maintained.

Integrations

List every system that calls you or that you call: payments, email, SMS, CRM, accounting, single sign-on, customer webhooks. For each one, record the direction, the credentials, the failure behaviour and whether the other side can change.

Some vendors will not move on your timetable. The new system then has to speak the old protocol for a while. That adapter is real work. Budget for it.

Aston Education is a website and jobs integration with a recruitment platform, not a legacy SaaS rewrite. It belongs in this conversation only as a reminder that the external system often sets the pace.

A practical architecture

For a typical B2B product that needs a new front end and a calmer back end:

• A server-rendered web application, often Next.js or a similar framework, so the obvious pages do not depend on a large client bundle.
• A small number of backend services. One is usually enough until load or team size forces a split.
• A relational database, background jobs for anything that must retry, and a queue where work can fail on its own.
• Authorisation in one place, checked on the server, not only hidden in the interface.

Microservices, a new event bus and three cloud providers are how a small product acquires the operational load of a large one. Add them when a measured constraint demands them.

The public marketing site is a separate question. If it sits on a dying CMS, you can rebuild the website on its own timeline. Do not block a security fix on a rebrand.

Testing

The old test suite, if it exists, documents intent. Do not throw it away because the syntax is old.

• Characterise the workflows you are moving with tests that describe inputs and outputs, before you change the implementation.
• Keep a staging copy of realistic data, with personal data removed or synthesised.
• Have a person who did not write the slice try the workflow.
• Compare outputs on the things that must match: an invoice total, a permission, a report row.
• Automate the regression checks you are tired of doing by hand.

A green pipeline that never runs the billing calculation is not quality assurance.

Human oversight is the control

Rules the team has to follow:

• Generated code is reviewed by someone who understands the workflow.
• The prompt is not the specification. The specification is a short note in the pull request.
• Dependencies suggested by a model are checked for maintenance and licence before they are added.
• No production data in prompts. No secrets in prompts.
• If nobody can explain a generated function, it does not merge.

The assistant does not lower the standard. It increases the volume of code that has to meet it.

Risks worth naming in the proposal

• Lost behaviour. A rare contract type, a manual override, a customer-specific rule.
• A long parallel run. Two systems, and a team maintaining both because the cut-over slipped.
• Data that does not round-trip. Reports that no longer match last year’s figures.
• Lock-in, moved rather than removed. A new platform you cannot leave is not a modernisation.
• Over-automation. An assistant that changes records without a person in the loop will do it wrongly at volume.

The mitigation is smaller slices, a way back, and a person accountable for the diff.

What actually drives cost and time

These factors do not collapse into a fixed percentage saving from AI.

• How many workflows must behave exactly as they do today.
• How clean the data is, and whether history must move.
• How many external systems are involved, and whether you control them.
• Security, privacy and audit requirements in your market.
• Whether the product may change, or only the implementation.
• Whether anyone still knows the old rules.
• Who will host and look after the new system.

AI assistance reduces time on specified, repetitive coding. It does not remove discovery, data reconciliation or the work of earning trust in the new screen. A proposal that quotes a guaranteed saving from AI is guessing.

A prototype of the riskiest workflow is often the right first purchase. Rapid prototyping is for that question. A prototype that answers “can this workflow live in the new architecture?” is useful. A prototype that only resembles a new homepage is not.

A sequence you can stop

1. Write the outcomes that must survive, and the ones you will drop.
2. Choose refactor, slice or rebuild with the table above. Record why.
3. Put the safety nets in place: a restore you have tried, staging, access control, a deploy you can undo.
4. Specify one workflow in enough detail that an implementer cannot invent the rules.
5. Build that slice. Review every generated change. Test it against awkward real scenarios.
6. Migrate the data for that slice and run it with a small group.
7. Plan the next slice only when this one is stable.

If step 4 cannot be written, do not start step 5. Another prompt will not discover a rule that nobody has stated.

Validate with a prototype

A prototype succeeds when it answers a named question.

Good questions include whether a billing exception can be represented in the new model, whether a customer can finish the task without the old back-office step, and whether an integration still accepts the payloads you must send.

Weak questions include whether a model can generate the whole application by Friday, and whether the new stack will reduce costs by a third.

Give the prototype a copy of anonymised data, the awkward role and the integration that fails. Then continue, narrow the scope, or stop. Stopping is a legitimate result.

The home for this work is bespoke apps and SaaS. If the legacy system is a public website rather than a product, start with the migration guide instead.

Limits of this guide

This is practice from delivery work, not a vendor benchmark. It does not quote a speed-up percentage for AI coding, because the honest range depends on the task and on the reviewer. For the search consequences of replacing a public site, use Google’s site-move documentation and the AI features guidance. For privacy duties, use the regulator that covers your customers.

Reviewed in November 2026. Nothing here is a fixed timeline or a guaranteed saving.