Strangler Migrations
One slice at a time, cut over while the rest runs
Big-bang rewrites of these systems fail for a reason that has nothing to do with technology: the old system embodies decisions nobody wrote down, and a rewrite has to rediscover all of them at once, at the end, under deadline. A strangler migration rediscovers them one slice at a time, with the old system still there to compare against. We run them for ASP.NET WebForms, VB6, Classic ASP, Access and FoxPro systems moving to .NET 8.
What we do
A slice is a unit users would recognize: the order-entry screens, the month-end reports, the customer maintenance workflow, the quote engine. The assessment sets the order; the first slice is chosen for value and for how cleanly it can be separated, not for size. Within a slice:
- Extend the harness. Characterization tests are written for the slice before any new code. On WebForms this usually means capturing ViewState-dependent flows end to end; on VB6 and FoxPro it means recording inputs and outputs at the boundaries where the code touches data.
- Rebuild. The slice is rebuilt on .NET 8 with the front end chosen in the assessment. AI tooling does the bulk transcription of business rules; engineers restructure, remove dead paths, and write the code as if it will be maintained for ten years, because it will.
- Route. A shim in front of the old application sends migrated paths to the new code and everything else to the old. Users see one system. Session and authentication are bridged so nobody logs in twice.
- Coexist on data. Until a slice's tables can move, both systems read and write the same database. We handle the ugly parts: Access linked tables, FoxPro DBF files that another process still writes, stored procedures with side effects.
- Cut over. The harness runs against both systems; when they agree, the slice goes live for a pilot group, then everyone. A rollback is one routing change.
- Hypercare. The engineers who did the work stay on call through the first weeks after cutover.
Who this is for
Owners of systems too tangled for the automated converters and too important for an offshore rewrite: typically the line-of-business application a mid-market company runs on, with a workflow, a screen family or a report set that needs to be off the old stack sooner than the whole system can be.
How we work with you
Slices are scoped together in conversation, informed by the assessment, and built by the engineers who scoped them. Work is billed hourly on a time-and-materials basis; a typical slice takes six to twelve weeks. The default target is .NET 8 (LTS) with Blazor or Razor Pages for screen-heavy applications, or ASP.NET Core APIs with a React front end where a separate front-end team exists. For Access and FoxPro, the data usually moves to SQL Server or PostgreSQL during an early slice. We will recommend, and we will follow your platform standards if you have them.
What it is not
- Not automated whole-codebase conversion. The output of those tools compiles and preserves every structural problem of the original.
- Not an offshore team with a US account manager. The engineers who scope the work are the ones who build it.
- Not open-ended drift. Each slice has a defined finish: harness green, traffic routed, rollback tested.
Next step
Bring us one workflow you need off the old stack. Contact us and we will tell you whether it is a good first slice, and what we would want to measure first.