Feb 24, 2026
Arnon Shimoni
Every billing platform has a pricing page, a feature matrix, and a migration checklist somewhere in their docs. The checklist usually starts with "Export your customer data" and ends with "Verify webhooks fire correctly".
What it doesn't mention: the six weeks your finance team will spend reconciling mid-cycle subscriptions. The 30 Slack threads about how to handle 47 customers on grandfathered pricing, or even tthe moment your CTO realizes the new system's "usage-based billing" doesn't actually support credits with rollover and expiration in the same wallet.
Migration is the reason most companies stay on "billing v1" longer than they should, and that's not because the current system works, but because switching feels worse.
Billing's Stockholm syndrome
I personally talk to companies every week who've already decided they need to move because their billing stack is some combination of a custom metering layer, hacked-together CPQ, a payment gateway like Stripe, and a reconciliation spreadsheet that one person on the finance team truly understands.
They know it doesn't scale and they've done the evaluation, maybe even got it to a shortlist.
When they really go deep into what that migration involves, they stay put for another year. I've been in that place twice myself in two different roles.
When I look at our customers, SEON ran 700 pricing plans through a single Excel spreadsheet. Montonio had a homegrown system pulling engineering away from product every month. Yapily was manually reconciling 200+ bespoke enterprise contracts. All of them knew they needed to move. The question was never "should we migrate?" It was "can we survive the migration itself?".
This is the part the industry doesn't like discussing, as vendors publish migration guides full of accordion menus and cutover checklists. They assume you have a clean data model, consistent subscription states, and a billing engineer who can map legacy plan IDs to new product catalogs.
Read that again - do you think anyone has everything 100% clean? I think every company above a certain size doesn't have those things. They have edge cases stacked on edge cases, held together by one engineer's institutional knowledge and a spreadsheet with 14 tabs.
That institutional knowledge is extremely hard to tap, even with the best AI tools.
The common checklist fallacy
A typical migration guide reads like this:
Export customer data
Map pricing plans
Configure new system
Run parallel billing
Cut over
Verify
Those six steps looks clean on a docs page and therefore they're "easy to buy".
In practice, step 2 alone can take months. I've personally seen this step take 8 months in one company I was at, and 2 years at another company.
"Mapping pricing plans" hides an incredible amount of complexity - it means understanding every exception, override, grandfathered rate, and mid-cycle proration rule that's accumulated over years of commercial decisions.
That's an archaeology project involving dozens of people sometimes.
For me, the real risk isn't even technical but instead commercial.
If you send one wrong invoice to a $200K enterprise customer during migration, you've created a trust problem that can take quarters to repair.
If you miss a revenue recognition rule and your auditor starts asking questions you can't answer.
If you break a webhook that triggers provisioning and customers lose access to features they're paying for.
What migration checklists promise vs. what actually happens
Step | What the checklist says | What actually happens | Who's gonna be stuck with it |
|---|---|---|---|
Export data | "Export customers as CSV" | Payment methods, mid-cycle states, and credit balances don't export cleanly | Engineer |
Map plans | "Map old plans to new plans" | 700+ pricing permutations with grandfathered rates, custom overrides, and undocumented discounts | Engineer + finance |
Configure | "Set up products and pricing" | Credit logic, rollover rules, multi-entity tax, and entitlements require architectural decisions | Engineer |
Parallel billing | "Run both systems side by side" | Someone has to compare every invoice line by line across two systems for 2-4 weeks | Finance team |
Cutover | "Switch production billing" | One wrong invoice to an enterprise customer creates a trust problem that takes quarters to fix | Everyone, at midnight |
Post-migration | "Verify and monitor" | Vendor support ticket queue. 48-hour SLA. Edge cases surface for 60+ days | You, alone - often over the weekend |
The checklist can't capture this.
Every company's billing mess is unique, and the edge cases that broke your v1 system are exactly the edge cases that make migration dangerous.
Why Solvimon deploys engineers, not docs
When we built Solvimon, we started from an "unfair" advantage, because our leadership had already done this at Adyen, with their internal billing engine that handle €970B+ in annual payment volume. At that scale, you learn something fast: no two migrations look alike, and no self-serve toolkit will survive contact with real billing data.
So we made a deliberate choice: instead of building a migration toolkit and pointing customers at documentation, we forward-deploy engineers directly into the migration.
A Solvimon engineer sits inside your migration, working alongside your finance and engineering teams, handling the translation between your old system's logic and Solvimon's architecture. They're reading your billing's webhook configs, understanding why customer #1337 has a pricing override that nobody remembers creating, and mapping the commercial intent behind every plan, not just the data schema.
The best infrastructure companies have always known that complex deployments need FDEs, not just deployed documentation.
We borrowed the playbook because billing migrations have more in common with infrastructure rollouts than they do with a standard SaaS onboarding.
Migration approaches compared
Self-serve migration | Guided onboarding | Forward deployed (Solvimon) | |
|---|---|---|---|
Who does the work | Your team, using docs | Split between your team and vendor support | Solvimon engineer, embedded in your team |
Plan mapping | You export, you map, you configure | Vendor provides templates, you fill them in | Our engineer audits your stack and owns the translation |
Edge case handling | Discovered at cutover | Flagged during onboarding calls | Caught before configuration starts |
Engineering time required | 2-3 engineers, 4-8 months | 1-2 engineers, 2-4 months | Near zero. Your engineers stay on product |
Cutover support | Documentation + ticket queue | Scheduled call during business hours | Engineer in the room, real-time resolution |
Post go-live | Support tickets, 24-48hr SLA | 2-week check-in period | 30-day stabilization with dedicated engineer |
Typical timeline | 4-8 months | 2-4 months | 2-6 weeks |
Risk profile | High. Edge cases surface late | Medium. Gaps between calls | Lowest. Continuous presence catches issues early |
What forward-deployed migration looks like
Phase 1: The Audit. Before we propose anything, a Solvimon engineer reviews your entire billing stack. Every system, every workaround, every spreadsheet. We find the edge cases before they find us during cutover. This isn't a form you fill out. It's a working session where we pull the complexity apart together.
Phase 2: Plan Translation. This is where most migrations stall. Your pricing plans carry years of commercial history: customer-specific discounts negotiated by a rep who left two years ago, tiered structures that evolved organically, credit logic that lives in application code rather than the billing system. Our engineer owns the translation. Your team reviews, we execute.
Phase 3: Parallel Operation. Both systems run simultaneously. Our engineer validates invoice accuracy line by line, across every plan type, every entity, every currency. Your customers never see the transition because we catch discrepancies before they reach an invoice.
Phase 4: Cutover with Presence. Go-live happens with a Solvimon engineer in the room, not on a support ticket queue. Real-time monitoring, immediate edge case resolution, direct access to someone who understands both your old system and the new one.
Phase 5: Stabilization. Go-live isn't the finish line. The 30 days after cutover matter more than the cutover itself. Our engineer stays through invoice reviews, reconciliation checks, and the inevitable "we found one more edge case" moments that every migration produces.
The goal throughout is that your engineers stay on product. The entire concept behind moving to billing v2 is to stop your engineering from maintaining billing code.
If migration requires your engineers to build a data bridge, we've failed before we started.
Our proof in two customers
When SEON came to us with 700 bespoke pricing plans in a spreadsheet, we didn't hand them a CSV template. Our team ingested every plan. The migration took less than two weeks. Within the first month, 75% of previously manual invoices were automated, and they surfaced revenue leakage across 10% of their invoices that nobody knew existed.
Their CFO, János Mátyásfalvi, put it simply: "I was skeptical if there was any solution out there that could relieve the team from an eternity of manual billing."
When Montonio needed to move off their homegrown system while processing 10,000+ invoices a month across multiple entities and currencies, we ran the migration alongside their team. Invoice-related support issues dropped 35% in the first month. Their VP of Product, Mike Oliinyk, said working with us felt "like having colleagues just working from another office."
That's the bar set. Not "vendor" or "platform provider", but colleagues who happen to have built billing infrastructure at Adyen scale.
Actual costs
Companies tend to compare migration cost against the subscription price of the new system. That's the wrong comparison.
The right one is migration cost versus the cost of staying.
SEON eliminated an estimated 5 FTE worth of manual billing work annually. Montonio got their engineering team back on product. Yapily cut 2 days from their monthly close and reduced manual invoicing by 98%.
Across our customer base, the pattern holds. The billing tax (those 2-3 engineers maintaining orchestration code, the 2-week close cycles, the revenue leakage hiding in spreadsheets) runs roughly $1M per year for companies at $15M+ ARR.
Migration is a one-time investment to eliminate a recurring cost. Every company that's gone through it told us the same thing: they should have done it sooner. What held them back wasn't the evaluation. It was the fear of the migration itself.
I understand this fear. I've faced it personally. It is very rational - and most vendors make migration your problem.
We put an engineer next to you and make it ours.
Solvimon was built by the team that scaled Adyen's billing engine to trillion-dollar volume. We've migrated companies from Stripe, homegrown systems, and everything in between. If your billing v1 is breaking and the migration is what's stopping you, talk to us. We'll send an engineer, not a checklist.