Implementation package
Parallel Replacement Beta
Build the replacement candidate first. Prove it before cutover.
A fixed-scope package that builds the first working version of a replacement system beside the old one — with explicit parity discipline and an early visible asset.
The old system keeps running. The new system becomes visible early. After roughly three to four months, for the agreed beta scope, the client owns a deployable beta, mapped business rules, a clean architectural spine, seeded or mirrored data, the first usable modules, documentation, and an open-question list — even if they do not continue with Smallbox.
This package is the executable plan that follows a System Report when the report recommends controlled twin replacement. It is not generic consulting, not a rewrite from scratch, and not "convert your MVC into our preferred architecture". The product is a controlled replacement candidate that preserves business behaviour while moving it into a clean, testable structure.
Start with the System Report: check whether your system is a fit.
Who this is for
Bounded legacy .NET / MVC systems where the System Report has found that gradual extraction would carry too much hidden business logic forward — where rules sit across controllers, jobs, SQL, admin overrides, and finance exports, and a frontend-first rewrite is, in practice, a quiet rewrite of business logic by a team that does not yet know the rules.
If the System Report concludes the system is a gradual-extraction case or a stabilise-first case, this is not the right package. The report exists to tell you that.
Fit conditions
This package requires:
- code and schema access;
- a named technical owner;
- a named operations / support owner;
- access to production-shaped data, or a safe anonymisation / snapshot path the engagement can build first;
- agreement that production cutover is not part of the Beta;
- business-rule confirmation time from the client — operations and finance availability for the parity-map sessions, not best-effort.
If any of these is missing or contested, the System Report is the right place to surface that. Starting the Beta without them puts parity verification on a foundation that cannot hold.
How the engagement is staged
Three stages. Each stage is decided after the previous one is read. No commitment to later stages is required up front.
Stage 1 — System Report · €3,000
The decision document. Chooses between gradual extraction, controlled twin replacement, or stabilise-first. Without this, the Parallel Replacement Beta is sold on a guess. Skip Stage 1 only if a previous report or a contractual equivalent already exists.
Payment: €2,500 to start, €2,500 on delivery. Four to five weeks of focused engineering, four to six weeks elapsed.
Stage 2 — Parallel Replacement Beta · €30,000 · ~3-4 months
The package this page is about.
Payment: €10,000 to start, €20,000 on beta delivery.
Stage 3 — Parity + Transition · €30,000 · ~3 more months
Brings the Beta toward production confidence. Decided only after the Beta is delivered and reviewed.
What is delivered after the Beta
- Business-rule and parity map. Every rule that must survive into the new system is named, owned by a business stakeholder, and classified into one of five buckets — preserve exactly, preserve behaviour and improve structure, change deliberately, do not copy, unknown and must be confirmed.
- Clean domain and application spine. The architectural backbone the new system stands on — DTO / Facade / BusinessService / Repository structure where appropriate to the system, not as a generic template.
- Database / repository layer. A real persistence layer over a schema that mirrors what the old system holds, anonymised where required.
- First usable modules. Read-only or limited-write, with the exact beta scope agreed before work starts. Examples for a typical marketplace: customer request capture; provider matching (read-only); customer / provider profile read; finance read-only export.
- Seeded or mirrored data approach. Production-shaped, anonymised data is seeded or mirrored where access allows. If that cannot be done safely, building the data-snapshot path becomes the first piece of work.
- Deployable beta environment. A non-production environment that client staff can log into and exercise.
- Documentation. Architectural decisions, the seeded / mirrored data approach, the parity map itself, the open-question list.
- Staff-preview access. The operations and support owners can walk through the agreed beta scope.
Accepted beta delivery
The agreed beta scope is deployed in a non-production environment, documented, demonstrated, and usable by the client for review. The client owns the beta codebase, parity map, documentation, seeded / mirrored data approach, and open-question list — even if they do not continue into Stage 3.
What is not delivered after the Beta
- Production cutover.
- Full migration.
- Replacement of all admin workflows.
- Full finance / payout parity sign-off.
- Ongoing retainer.
- Emergency production support.
These belong to Stage 3 — Parity + Transition, not to the Beta. They are the work the next package is for.
What happens if the client stops here
The client owns a real asset: a deployable beta system, a parity map of the business rules, documented architectural decisions, and an open-question list. The old system continues to run unchanged. Smallbox does not retain the work. The client may continue with another vendor, another team, or themselves.
This is intentional. The Beta is structured so the client commits to evidence, not to a path they cannot reverse.
What happens if the client continues into Stage 3
Stage 3 — Parity + Transition · €30,000 · ~3 more months
Purpose: bring the Beta toward production confidence.
Deliverables
- Main workflows completed for the agreed scope.
- Migration scripts — runnable end-to-end against a snapshot of production-shape data.
- Old / new comparison reports across financial flows, eligibility, status semantics, and notification timing.
- Staff scenario testing — the hardest weekly cases run through both systems in parallel.
- Parity verification.
- Bug fixing.
- Missing edge-case closure.
- Deployment / cutover plan.
- Rollback plan.
- Acceptance walkthrough.
Timing inside Stage 3
- Most of Stage 3. Finish main workflows and validation machinery. By the end of this period, the replacement candidate should be running with the agreed main workflows and data.
- Final month of Stage 3. The confidence month. Parity checks, staff testing, missing details, bug fixes, acceptance.
The Beta builds the replacement candidate. The Transition proves whether it can safely replace the old system.
The conservative version of the timing promise:
By the time the final month of Stage 3 begins, the replacement candidate should be running with the agreed main workflows and data. The final month is reserved for confidence, not rushed construction.
The confidence month is a deliberately boring month. Refinement, edge cases, missing business rules, sanity checks, acceptance — not new feature construction. The confidence month should feel controlled, not dramatic. If major new construction is still happening there, the transition risk has increased.
How we ensure the new system matches the old one
This is the safety mechanism of the controlled twin path. Without it, the package is a rewrite fantasy. With it, the package is controlled delivery with explicit exits.
Parity map
Every business rule that must survive is named, owned, and classified. Built in the first month, confirmed before significant code is written, revisited at the end of each stage.
Captured business scenarios
The hardest weekly cases — support tickets, finance reconciliation events, admin overrides, dispute recoveries — are captured as scenarios the new system has to reproduce. Captured early, not discovered during cutover.
Seeded or mirrored data
Production-shaped, anonymised data is seeded or mirrored where access allows. If that cannot be done safely, building the data-snapshot path becomes the first piece of work — not an assumption left to the transition phase.
Old / new reconciliation reports
For finance flows, old-system and new-system outputs are compared row-by-row over historical traffic. Every discrepancy is classified as expected, bug-in-old, bug-in-new, or parity gap to fix — and named explicitly until each one is resolved.
Staff scenario testing
Support and operations exercise the hardest cases against both systems in parallel. Behaviour differences are surfaced explicitly, not glossed over.
Finance / output comparison
Money movement — commission, VAT, payout, refund unwinding — is compared end-to-end before any cutover decision. Money is the preserve-exactly bucket; parity here is non-negotiable.
Shadow validation, where possible
Once confidence is high, real production traffic is mirrored against the new system without affecting customers. Outputs are compared. The new system handles real load before it handles real responsibility.
Payment structure
| Stage | Price | Payment | Duration |
|---|---|---|---|
| System Report | €3,000 | €1,500 to start, €1,500 on delivery | 4–5 weeks of focused engineering, 4–6 weeks elapsed |
| Parallel Replacement Beta | €30,000 | €10,000 to start, €20,000 on beta delivery | ~3-4 months |
| Parity + Transition | €30,000 | €10,000 to start, €20,000 on accepted transition delivery (split agreed before Stage 3 begins) | ~3 more months |
Each stage is decided after the previous one is read. Continuation is never assumed.
Acceptance criteria
Beta acceptance (end of Stage 2)
- The agreed beta scope is deployed in a non-production environment.
- The scope is demonstrated end-to-end to the technical and operational owners.
- The parity map is documented and confirmed by the operations stakeholder named at intake.
- Documentation describes the architectural decisions, the seeded / mirrored data approach, and the open questions remaining.
- Client staff can log in and exercise the beta scope independently.
Parity + Transition acceptance (end of Stage 3)
- Migration scripts run end-to-end against a snapshot of production-shape data.
- Reconciliation reports cover money movement, eligibility, status semantics, and notification timing for at least one month of historical traffic.
- Staff scenario testing has surfaced and resolved the hardest weekly cases.
- Cutover plan and rollback plan are documented and reviewed.
- Acceptance walkthrough completed with the technical and operational owners.
What this package is not
- Not a generic consulting retainer.
- Not "I will take your MVC and convert it to my preferred architecture." Architecture is a means, not the product.
- Not a promise to finish in six months no matter what. Month six is reserved for confidence, not for rushed construction.
- Not a rewrite from scratch. The old system runs throughout. The new one is built beside it. They are compared. Cutover happens only after confidence — and only if Stage 3 is bought.
How this package fits with the rest of Smallbox's work
- NaboWorks case study — the source world this package is reasoned from. A 12-year-old ASP.NET MVC service marketplace where the modernization decision is real and the parity map carries weight.
- NaboWorks System Report — the diagnostic decision that recommends this package. Seven ranked findings, a change-safety plan, and a primary outcome that names the question this package is the answer to.
- Parallel Replacement Beta (this page) — the executable package that follows.
The chain is deliberate: case study sets the world, report makes the decision, package executes it. None of the three skips a step.
How to start
The first step is always the System Report. It is the only way to know whether your system is a fit for this package — or for one of the alternative paths it might recommend instead.
Send your system context. The report begins on an agreed start date, once scope, access, and the first payment are confirmed.
The decision document that comes before this package is the System Report.