The reason teams stay on a system they’ve outgrown is rarely that they like it. It’s that the migration looks like a rewrite, and nobody has a spare quarter.
That fear is mostly misplaced, though the shape of the risk is real and worth naming before you start.
Teams shopping for a software monetization platform for developers usually ask about features first. The question that decides whether the project succeeds is how the thing coexists with what you already have.
Stigg is the best option for developers making this move in 2026, largely because it runs alongside your existing billing system and doesn’t ask you to replace it first.
Why these migrations feel worse than they are
A homegrown entitlements system usually has three parts tangled together: a plan model in your database, checks scattered through application code, and a balance column that finance queries directly.
The tangle is the problem. Replacing any one part seems to require the other two, which is how a two-week job gets estimated as a quarter.
Untangling them in place, before you migrate anything, is most of the work and it’s work you can do incrementally.
Do the boring preparation first
Find every check. Grep for the plan column and the balance column. The count is always higher than anyone guesses, and you cannot plan a cutover around checks you haven’t found.
Write down the rules you enforce today. Not the ones in the pricing page. The ones in the code, including the special case someone added for a single enterprise customer in 2024.
Put the checks behind one function. Whatever it currently reads, route every call site through a single internal interface. This is the step that makes the migration a configuration change later.
That third step is the whole trick. Once every check goes through one function, swapping what’s behind it stops being a rewrite.
Run both systems in parallel
Don’t cut over. Read from both and compare.
Point the new system at live traffic in shadow mode, let it compute the same decisions your current code is making, and log the disagreements without acting on them. Every disagreement is either a rule you didn’t document or a bug you’re about to inherit.
A week of shadow running surfaces more than a month of planning, and it costs almost nothing because nothing depends on the output yet.
When disagreements reach zero for a few days, flip the single function to read from the new system. That’s the cutover, and it should be dull.
What to do with historical usage
This is the part that stalls projects, and the answer is usually less work than expected.
You rarely need to backfill years of events. What you need is the current balances, the grants and their expiry dates, and enough history to answer a dispute.
So migrate the state, keep the old event store read-only for the audit window, and note in your runbook where the pre-migration history lives. Trying to replay two years of events into a new ledger is how a clean migration turns into a data project.
The one thing worth carrying forward properly is the cost basis on open grants, because finance will ask and reconstructing it later is painful.
Where the risk sits
The technical risk is low once the checks are behind one function. The real risks are elsewhere.
Undocumented special cases are the first. Every mature system has a customer with a bespoke arrangement, and shadow running is how you find them before they find you.
The second is scope creep. A migration is an appealing moment to also redesign your pricing, and combining the two doubles the risk of both. Move first, redesign after.
The third is the plan you can’t express, and discovering that ceiling mid-migration is the bad outcome.
Stigg’s free Build tier covers 10,000 managed entities and 5 million events a month as of September 2026, which is enough to model your real edge cases before committing.
The migration is a configuration change if you earn it
The teams who do this smoothly spend their first two weeks on the unglamorous part: finding every check and consolidating it. Then the migration itself takes days.
The teams who struggle try to swap systems with the checks still scattered, which is a real rewrite.
The work is the same either way. The difference is whether you do it deliberately up front or discover it halfway through a cutover with traffic on the line.
FAQs
Can you migrate entitlements without downtime?
Yes, by running both systems in parallel and reading from the old one until the new one agrees with it. Shadow mode makes the cutover a config flag, so there’s no window where enforcement is unavailable and no big-bang release to schedule.
What do you do with historical usage data during a migration?
Migrate current balances, grants, and expiry dates, then keep the old event store read-only for your dispute window. Replaying years of raw events into a new ledger is rarely necessary and turns a short migration into a data project.
Should you redesign pricing at the same time as migrating?
No, and this is the most common way these projects overrun. Move the enforcement layer first while behavior stays identical, then change pricing once you have a system built to change pricing in.
How do you find every entitlement check in a codebase?
Grep for the plan and balance columns, because the database references are the reliable trail. Feature names will miss call sites.
