Rebuilding a business application is not the same as rebuilding a website: you are replacing a tool whose rules nobody fully remembers any more, while it keeps running and people keep using it. The sequence is well established, yet it rarely appears in sales proposals — those talk mostly about technology. Here are the real stages, in the order they arrive, and what gets decided at each one.
What makes a project large: surface, not volume
The first surprise for many clients: the number of records barely matters. A few thousand files, a few hundred concurrent users at peak — no modern server flinches. At that scale the only genuine load question is bulk e-mail, and it is answered by relying on a specialist routing service.
What makes the project large is its functional surface: several spaces (public site, member area, management area, administration), thirty-odd business functions, and above all roles that intersect with scopes. Two people holding the same role do not see the same rows, depending on the region, department or delegation they are responsible for. This is not a list of roles, it is a matrix of roles by scope — and every single screen has to filter its data accordingly.
That gap — small in volume, vast in surface — is what should govern the architecture and the budget. A project costed on volume is an under-costed project.
Stage 1 — Scoping, before a single line of code
Scoping commonly accounts for a tenth of the total effort. It is what saves you from having to rebuild the rebuild.
In practice: a series of business workshops, one per major domain, where users are made to describe what the current tool actually does — including the workarounds, the parallel spreadsheets and the rules nobody ever wrote down. The outputs: detailed specifications, the target data model, the site map and mock-ups for each space, an architecture document and the data protection impact assessment.
A validation workshop with a panel of real users — not just the steering committee — closes the stage. It costs a day and clears up misunderstandings that, discovered six months later, cost weeks.
Stage 2 — The foundations, permissions first
Next comes the invisible infrastructure: staging and production environments, an automated delivery pipeline, authentication (password policy, two-factor), an audit log, an accessible and responsive component system.
And, at the same moment, the permission model. This is deliberate: any screen built before permissions are settled will have to be rebuilt. The right instinct is to express them as configured rules rather than code — a roles × scopes matrix that is configured can be read back, audited and changed without a new engagement; the same matrix scattered through the code is debt from day one.
Stage 3 — Business increments, delivered in batches
The rest is split into work packages, each producing an increment that can be accepted in staging, documentation included. The client sees something working every few weeks, rather than a final demonstration a year later. It is the best protection against tunnel effect, and the best renegotiation tool along the way: you can postpone a package, you cannot postpone a tunnel.
The usual order follows the dependencies: the people directory first, then the management cycle (membership or case file, invoicing, online payment, adjustments), then messaging and surveys, then data exploitation, and finally the editorial site.
One distinction is useful for the budget: what is standard and what is not. A content site, a directory, search, a job board are classic needs; built on existing components rather than written from scratch, they account for less than a quarter of the effort. Everything else — the rules specific to your organisation — cannot be reduced. That is where the money belongs, and where bespoke work earns its keep.
Stage 4 — Data migration, the line item everyone underestimates
No stage holds more unpleasant surprises. A database in service for fifteen years contains free-text fields where undocumented information has taken up residence, duplicates, obsolete codes and conventions that changed three times.
The sequence that holds: an audit of the existing database before the final costing; a field-by-field map and written transformation rules; replayable migration scripts — you never migrate only once; anomaly reports handed to the client, who decides the doubtful cases; at least three dry runs; and finally acceptance testing on the data itself, not only on the screens.
It is the one line item that can reasonably be announced as revisable after the audit. A supplier who quotes it as a fixed price without having opened the old database is taking a risk — or has already priced that risk in.
Stage 5 — Acceptance, cutover, warranty
Functional acceptance belongs to the client: their teams run their real cases in staging, defects are fixed, and round it goes again. Then the cutover, in a chosen window, followed by a fitness check — the tool does what it must — and then a period of regular service, watching how it behaves under real conditions.
The old system stays available read-only for a few weeks. That safety net is almost never used; it costs little and completely changes the mood on the day.
Documentation is handed over at every stage, never at the end
A simple rule that changes how a project feels: every stage comes with its own documentation hand-over — technical documentation and user documentation, updated and delivered alongside the increment they describe, rather than promised for later.
Scoping hands over its specifications and architecture document. The foundations hand over the database schema, the permission matrix and the operating procedures. Each business package hands over the manual for the screens it opens, by user profile — what a manager sees is not what a member sees. Data migration hands over its transformation rules and anomaly reports. Go-live hands over the operations handbook and the training material.
Postponing that effort to the end produces documentation written from memory, in a few days, by someone who has forgotten why a given rule exists — and that nobody reads. Written as you go, it is useful immediately: it is what makes acceptance testing, training and later hand-over to another team possible. It is also the difference between real reversibility and contractual reversibility.
Two kinds of data, two tools
An architectural note that recurs on every one of these projects. Editorial content and management data do not obey the same laws: the first changes often, is written by many hands and must be indexed by search engines; the second changes rarely, is subject to fine-grained permissions and must never leak.
Handling both with a single tool means giving way on one of them — either a painful editorial back-office, or personal data managed with the casualness of a brochure site. Separating them, with a shared session between the two, is almost always the right call. It is also, in practice, the most delicate piece of architecture in the project: to be dealt with early, never at the end.
Reversibility is prepared on day one
A last point, often relegated to a contractual annex although it governs everything else: what happens if the supplier disappears?
The answer rests on three choices made at the start. The data lives in a standard database whose schema is yours, not the internal schema of a product: it stays usable even if the application layer stops. The code, the infrastructure described as files and the operating documentation are handed over as you go, not at final delivery. And third-party dependencies are explicitly distinguished from the code written for you, licences included.
A simple test, worth asking at the kick-off meeting: “if you stop tomorrow, what is left that works, and who can run it?” The quality of the answer says more than any brochure.
How long does it take?
For an application of this surface — several spaces, a permission matrix, a complete management cycle and a data migration — expect somewhere between a year and eighteen months from the first workshop to going live, scoping included. Projects promising three months do not remove the work: they move it past go-live, where it costs the most.
Thinking about replacing an ageing application? We carry out audits of the existing system with written costings and a work-package plan, independently of any later build — let's talk.