01
Inventory
Read the source. Map supported configuration and exceptions.
Migration · A controlled move
Move the operation. Not the uncertainty.
Start with a read-only inventory and a plan you can inspect. Our purpose-built migration tooling handles repeatable configuration; people own the exceptions, validation, and cutover.
02
Approve
Review the dry-run plan, scope, ownership, and costs.
03
Validate
Build in dependency order and test the agreed call paths.
04
Cut over
Move campaign by campaign. Keep carrier porting on its own timeline.
Two lanes
Where you're coming from changes the work.
We do these often enough to know which parts are routine and which parts need a person. Rather than average the two into one reassuring number, here is each.
From Ringba
A single day
This one is routine.
Ringba is the migration we do most often, and it is the one we have tooling for end to end — a straightforward account can be migrated in a single day. We connect to your Ringba account read-only, pull the whole configuration, and rebuild it on Moja in dependency order — buyers and publishers first, then numbers, targets, RTBs and RTB groups, routing plans, campaigns, and finally your outgoing webhooks. You approve the plan before any of it is created.
- Read-only at the source — the migration can only issue GET requests against Ringba
- A dry run produces the full build plan before anything is created
- Every source and destination request is visible in a trace you can read
- Re-runnable without duplicates — everything is keyed to its original ID
From an enterprise platform
Under a week to first campaign live
This one we do with you, by hand where it matters.
Enterprise books don't come with a clean export, and pretending otherwise is how migrations stall. So we sit down with your setup: someone from our side owns the account, walks your campaigns, buyers, integrations, and reporting definitions with your team, and rebuilds them against a checklist for your campaign type rather than re-deriving the work per account.
- A named owner on our side for the whole migration, not a ticket queue
- Per-archetype build checklists — Ringba import, fresh build, RTB-heavy, voice agent
- Integrations verified before cutover: RTB partner pings, webhooks, ad-platform connections
- A test call end to end, with you on the line, before real spend moves
The mechanism
We read your account, not your documentation.
Nobody's runbook matches their live configuration, and asking you to write one is asking you to do the migration twice. We connect to the account and read what is actually there.
The import runs in dependency order, because the objects depend on each other and building them out of order is how migrations produce half-configured campaigns: buyers and publishers, then numbers, targets, RTBs and RTB groups, routing plans, campaigns, and finally your outgoing webhooks.
Everything is keyed to its original identifier, so the import is safe to run again. A second run updates what exists rather than creating a duplicate of it — which matters, because migrations are never one clean pass.
Every request we make against your current platform and every request we make against Moja is recorded, and you can read the trace. If something didn't come across, you can see what was asked and what came back rather than taking our summary of it.
What comes across
- Campaigns
- Buyers
- Publishers
- Targets
- Numbers
- Ring trees
- Routing plans
- RTBs and RTB groups
- Outgoing webhooks
A specific list rather than “everything,” because “everything” is never true and the exceptions are further down this page.
You see the plan before anything is built.
Every migration runs as a dry run first. It produces the complete build plan — every buyer, publisher, target, routing plan, campaign, and webhook we intend to create, with the values we intend to give them.
You read it. You tell us what's wrong. Nothing is created on your Moja account until you say go, and when it is, it is the plan you read.
Nothing changes in the platform you're on.
The migration is read-only at the source. It can only issue read requests against your current platform — that is enforced in the software, not promised in a process document. It cannot create, edit, disable, or delete anything in the account you're still running your business on.
Which is what makes running both platforms in parallel safe, and why we recommend it rather than tolerate it.
Who does what
Most of the rows are ours.
The parts that are yours are yours because they have to be — an approval, a business decision, or information your current platform never held.
| Step | Owner | What it means |
|---|---|---|
| Read your current accountRead-only connection, full configuration inventory. | Moja | Read-only connection, full configuration inventory. |
| Map it to MojaField-by-field translation, each field graded by how mechanical it is. | Moja | Field-by-field translation, each field graded by how mechanical it is. |
| Build the planA dry run showing exactly what will be created, before it is. | Moja | A dry run showing exactly what will be created, before it is. |
| Approve the planYou read the plan and say go. Nothing is created before you do. | You | You read the plan and say go. Nothing is created before you do. |
| Fill the gaps Ringba never storedMoja requires a few buyer and publisher fields Ringba doesn't hold — address, phone. Collected once, in intake. | You | Moja requires a few buyer and publisher fields Ringba doesn't hold — address, phone. Collected once, in intake. |
| Build itBuyers, publishers, numbers, targets, RTB, routing, campaigns, webhooks. | Moja | Buyers, publishers, numbers, targets, RTB, routing, campaigns, webhooks. |
| Rebuild call flows and ring treesDecided with you per campaign — simple priority logic becomes a Routing Plan, branching logic becomes a Call Flow. | Moja | Decided with you per campaign — simple priority logic becomes a Routing Plan, branching logic becomes a Call Flow. |
| Verify integrations and run the test callRTB pings, webhooks, postbacks — then a live call with you on it. | Moja | RTB pings, webhooks, postbacks — then a live call with you on it. |
| Decide each cutover waveCampaign by campaign, at your pace. We run alongside until you're done. | You | Campaign by campaign, at your pace. We run alongside until you're done. |
| Port numbersYour decision and your current carrier's timeline — see the note below. | You | Your decision and your current carrier's timeline — see the note below. |
Timing
What actually takes how long.
Coming from Ringba: a single day. It is the migration we run most often and the one we have tooling for end to end, so a straightforward account gets read, planned, and rebuilt inside a day. The build is not the constraint — your approval of the plan and your appetite for cutting the first campaign over usually are.
Coming from an enterprise platform: first campaign live inside a week. Intake, build from what we read, integrations verified, a test call that passes with you on the line, and then the first live routed call. That last one is the milestone we measure, and we take it from platform telemetry rather than from someone remembering to update a status.
Then the rest of the book, in waves, at your pace. Moving a campaign is a technical decision. Moving your whole business is an operating-risk decision, and it is yours to time. We run alongside your current platform for as long as that takes.
The exception, stated plainly: number porting is not on our clock. Your current carrier sets the date, and no vendor who tells you otherwise controls it either. We file it, chase it every two business days, and report the status — and we usually recommend standing up fresh Moja tracking numbers first so routing and attribution are proven before your production numbers move.
Straight talk
What doesn't come across.
Before you ask, and not buried in an FAQ. Every migration has these; the difference is whether you find out now or in week three.
Your call history doesn't come with you.
Historical calls stay in Ringba. Keep your exports for reconciliation — we recommend it out loud. New calls report in Moja from the first routed call.
Call flows and IVR are rebuilt, not imported.
Routing plans import. Branching logic and IVR we rebuild with you, and often simpler than it was — Ringba ring trees frequently map to a Routing Plan rather than a Call Flow.
RTB counterparties are handled deliberately, not mechanically.
We don't claim automated RTB migration. There are one-click RTB templates for Ringba that shorten the rebuild, and we keep an interoperability path open during cutover so your partners aren't forced onto new endpoints all at once.
Caps and de-duplication get reviewed by a person.
Ringba caps are dimensional and Moja's model is shaped differently. We translate them with you rather than assuming the mapping is clean.
Number porting runs on your current carrier's clock.
Porting is the long pole on every migration and the part nobody on our side controls — the losing carrier sets the date. It gets its own status and we chase it every two business days. We usually recommend standing up fresh Moja numbers first and porting production numbers once routing and attribution are proven.