Every team running on a .NET framework eventually hits the question: &quot;what
happens if we want off?&quot; The opinions stop matching. The license fails
procurement. The maintainer pivots. Pick your reason.
Standard answers are all bad: big-bang rewrite (code freeze, ugly
weekend, a year of regression hunts); microservices first (a new
architecture to dodge the old one, plus a network); stay forever
(the framework becomes the application).
We picked a fourth: strangler fig with a shared database. Six months
of normal feature work, zero downtime, and at the end the old framework
was simply gone. The concrete case was ABP → <a href="https://granit-fx.dev" target="_blank" rel="noopener nofollow">Granit</a>,
but the pattern travels.
<h2>The setup</h2>
Two web hosts. Same database. Same OIDC issuer. An ingress routes per
URL prefix. New modules ship in the new host; legacy modules keep
serving until they get ported. The ingress flips routing one prefix at
a time.
<pre><code>browser → Ingress (YARP)
 │
 ┌────────┴─────────┐
 /api/legacy/* /api/orders/*
 ▼ ▼
 ┌────────┐ ┌─────────┐
 │ old fx │ │ new fx │
 └───┬────┘ └────┬────┘
 └────┬─────────────┘
 ▼
 Shared DB + OIDC
</code></pre>
Every strangler-fig post draws that diagram. The part they skip: **what
stops the shared database from becoming a graveyard?** Two hosts
writing the same tables is the easy way to mismatched migrations,
audit columns that lie, and tokens that work on one host but not the
other.
Four rules.
<h2>Rule 1 — Schema ownership belongs to whoever wrote the table first</h2>
Exactly one host per table generates EF Core migrations. The other
configures the entity as read-only. When ownership transfers (because
the old host has been decommissioned for that prefix), it moves in a
dedicated PR: new host generates the next migration, old host’s
<code>DbContext</code> drops the <code>DbSet&lt;T&gt;</code>, <code>__EFMigrationsHistory</code> stays
consistent.
The trap: never let both hosts run <code>Add-Migration</code> against the same
table in parallel. Migration history is per-schema, not per-host. Two
hosts generating against the same schema will collide in
<code>__EFMigrationsHistory</code> and the next deploy fails. We learned this in
staging. We did not learn it in production.
<h2>Rule 2 — Audit and tenant column shapes are frozen</h2>
The old framework used <code>CreatorId</code> / <code>CreationTime</code>. The new used
<code>CreatedBy</code> / <code>CreatedAt</code>. Tempting to rename — dangerous.
Two columns serving the same field while both hosts are live is one
bug. So the new host’s entities mapped to the legacy physical names:
<pre><code>modelBuilder.Entity&lt;InventoryItem&gt;(b =&gt;
{
 b.Property(e =&gt; e.CreatedAt).HasColumnName(&quot;CreationTime&quot;);
 b.Property(e =&gt; e.CreatedBy).HasColumnName(&quot;CreatorId&quot;);
});
</code></pre>
Ugly. We accepted ugly. The rename happened exactly once, during the
decommission of the old host, in a single PR that shipped after
the old host was already gone from production.
The trap: don’t carry the rename forward in small batches.
Half-renamed columns mean half-broken queries.
<h2>Rule 3 — OIDC stays unchanged</h2>
Both hosts pointed at the same issuer (Keycloak) with the same <code>aud</code>
and signing key. Tokens minted for the old host worked unchanged on
the new. No parallel user store. No token exchange. No &quot;auth
migration&quot; sub-project.
Easy to satisfy if you started with an external IdP. If your old
framework is its own identity provider, either keep it issuing tokens
during the cutover (consume them on both hosts) or stand up an OIDC
server in the new framework with the same signing key. The second is
the eventual destination; the first is the bridge.
<h2>Rule 4 — No cross-host transactions</h2>
Two hosts cannot share a transaction. If a write spans modules owned
by both, it cannot be atomic across them. We solved this the same way
microservices do: domain events plus the outbox pattern, even though
both hosts shared a database.
When the new host’s Inventory module updated stock and needed to
notify the old host’s Order module, it raised a <code>StockChanged</code> event
into the outbox. A Wolverine relay (in the new host) picked it up
after commit and dispatched to the old host’s in-process bus. The DB
transaction stayed local on both sides.
The trap: never write to a table you don’t own from the other
host. Schema ownership (Rule 1) plus no-cross-host-transactions (Rule
<ol start="4">
<li>kept the migration mechanical instead of forensic.</li>
</ol>
<h2>The decision that nearly broke it</h2>
The old framework used <code>int</code> primary keys on hot tables. The new only
supports <code>Guid</code>. Discovered in week two — after we had already started
porting modules.
We picked the deterministic UUID v5 strategy:
<pre><code>-- Add new key column, backfilled with deterministic UUIDs.
ALTER TABLE inventory_items ADD COLUMN id_new uuid;

UPDATE inventory_items
 SET id_new = uuid_generate_v5(
 &#x27;a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11&#x27;, id::text);

-- Rewrite every FK the same way (one statement per FK).
ALTER TABLE inventory_movements ADD COLUMN inventory_item_id_new uuid;

UPDATE inventory_movements
 SET inventory_item_id_new = uuid_generate_v5(
 &#x27;a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11&#x27;, inventory_item_id::text);

-- Swap the primary key.
ALTER TABLE inventory_items DROP CONSTRAINT inventory_items_pkey;
ALTER TABLE inventory_items DROP COLUMN id;
ALTER TABLE inventory_items RENAME COLUMN id_new TO id;
ALTER TABLE inventory_items ADD PRIMARY KEY (id);
</code></pre>
The trick: <code>uuidgeneratev5(ns, source_id::text)</code> is deterministic.
Same <code>int</code> always produces the same <code>Guid</code>. Every FK referencing the
old <code>int</code> produces the same new <code>Guid</code> independently — no mapping
table, no joins to backfill, no downtime.
The critical sequencing — and this nearly took us down in production
— is that the **old host’s entity must be regenerated to <code>Guid Id</code>
before the SQL runs**. If the old host stays on <code>int Id</code> after the
column type changes, its EF Core model diverges from physical schema
and every read on that table throws. We caught it in a Friday
staging dry-run. It would have been a Saturday outage.
<h2>What the pattern doesn’t help with</h2>
Three things the strangler fig cannot solve:
<ul>
<li>Schema-level concept changes. New framework wants multi-tenancy</li>
</ul>
as a discriminator column, old wanted it as schema-per-tenant?
Can’t strangler-fig that — one of them has to give, in a planned
window. It was the only off-hour work we did.
<ul>
<li>UI tightly coupled to one framework. PascalCase vs camelCase,</li>
</ul>
auto-routed application services, that kind of thing. Either run
an anti-corruption layer in the ingress or migrate the UI
separately.
<ul>
<li>Compliance gaps during cutover. New framework’s GDPR features</li>
</ul>
only apply to modules already ported. Until the last legacy module
is gone, the legacy posture is the floor. Port PII-heavy modules
early.
<h2>The last ten percent</h2>
After five months the ingress had stopped routing to the old host. We
left it as a read-replica safety net for two weeks, turned it off,
deleted the legacy NuGets two weeks later. No flag day, no
maintenance window, no all-hands.
The thing nobody mentions about strangler-fig migrations: **the last
ten percent is the hardest**. By the time you’re down to two modules
in the legacy host, the cost of touching legacy code exceeds the cost
of pushing through the migration — but the urgency is gone, because
the system works. Budget for the last two modules taking as long as
the first ten.
<hr>
The framework-specific mappings (ABP <code>CrudAppService</code> → Minimal API,
<code>IDistributedEventBus</code> → Wolverine, full int→Guid recipe with FK
rewrites) live in the [ABP → Granit migration
guide](<a href="https://granit-fx.dev/migrating-from/abp/" target="_blank" rel="noopener nofollow">https://granit-fx.dev/migrating-from/abp/</a>). The four rules
above are the part that travels to any .NET framework swap.
Source: <a href="https://github.com/granit-fx/granit-dotnet" target="_blank" rel="noopener nofollow">github.com/granit-fx/granit-dotnet</a> (Apache-2.0)

Jean-François Meyers

A practical account of migrating a .NET application from one framework (ABP) to another (Granit) using the strangler fig pattern with a shared database, achieving zero downtime over six months. Four concrete rules govern the migration: strict schema ownership per host, frozen audit/tenant column shapes with EF Core column name mappings, a single shared OIDC issuer, and no cross-host transactions (solved via domain events and the outbox pattern). A near-critical issue arose from mismatched primary key types (int vs Guid), resolved using deterministic UUID v5 generation to backfill keys and foreign keys without a mapping table. The post also covers limitations of the pattern — schema-level concept changes, tightly coupled UIs, and compliance gaps — and warns that the final 10% of legacy modules takes disproportionately long once urgency fades.

How we replaced our .NET framework without downtime - the shared-database strangler fig