Quick answer: A halted migration on Devotel Orbit — a job the worker stopped mid-flight, usually discovered after the wizard closes — is a recoverable state, not a lost one. Every platform-migration job is durable: the job id, its failure reason, the row counters, and the conflict list persist under Settings → Migrations, and rows already written stay written. Recovery is one of three paths: cancel whatever is still in flight and re-run the wizard (retry), roll back to delete exactly the contacts the job created, or escalate with the job id and request id. Orbit itself has no pause button — "resume from a checkpoint" means a deliberate re-run over the same connection, with the duplicate policy you picked at preview deciding each collision with the partial rows. This walk covers the failure shapes, the three paths, and the pre-flight that makes the retry stick; it slots next to the migrate-from runbooks that got you here — Plivo, Sinch, Genesys, Avaya PBX, and OpenPhone.
What a halted migration actually is
Two different surfaces run "a migration" on Orbit, and recovery differs between them — name which one you are in before anything else.
The platform-migration wizard — the one-click importer that pulls an upstream platform's configuration and audience into your tenant (reachable from onboarding, or later under Settings → Import; the Klaviyo wizard opens directly at /import/klaviyo). It ships with five source connectors: Twilio, Telnyx, Klaviyo, MessageBird, and Front. The Klaviyo importer post walks one of them end to end; the import lifecycle concept page covers the shared contract. Each confirmed run persists as one import job with a single status: pending → running → succeeded | failed | cancelled. The three end states are terminal — a job in any of them never moves again.
The CSV contact import — the groomed file path the OpenPhone runbook leans on for contact lists. It runs as an async job through the same pending → running → completed | failed | cancelled lifecycle, with the failure classes documented in the contact-import troubleshooting page.
A halted migration is either surface's job dying before succeeded: an upstream credential that expired, a rate limiter that took down the preview, a source account that was mid-change, or a queue that dropped. What you do not have is a data-integrity problem waiting to happen — the worker writes between batches and every row it wrote is owned by a specific job id, so recovery is always scoped to what that one job did.
The four failure shapes, and the fix behind each
Nearly every stalled import matches one of these. Identify the shape first; the recovery path below assumes you did.
- Missing export prerequisites. The most common and the cheapest to prevent. The wrong Klaviyo key, a Twilio subaccount the Connect flow cannot reach, a source account the credential cannot read at the chosen scope. Prevention is the wizard's own contract: the dry run — step 3 — never writes anything. Run it as many times as you need; if the upstream moved since you connected, re-run the preview and the counts refresh. A failed dry run never changes anything on either side.
- The unported number. Twilio and Telnyx imports carry phone-number inventory as imported metadata — a port request, not a switch. If your numbers never actually ported, nothing downstream of them (senders, registrations, live traffic) moved. The recovery is the number-porting guide and the porting docs: a bulk portability check, in-platform LOA, FOC dates, and porting webhooks — and on a carrier rejection, the amend window plus the supplement endpoint means the correction ships without restarting the calendar.
- Templated-content drift. Klaviyo email/SMS templates land as Orbit message templates — exact text bodies, duplicated intact. What drifts is the dynamic content inside them: variable names, conditional blocks. The template imported is the template you had on the source; review each one in the library before a campaign references it, and use the rendered-preview to see what a given channel recipient will actually receive before any send touches a recipient.
- Consent downgrade on contacts. The silent one. Opt-out and consent state travel with imported contacts — a suppressed recipient on the old platform stays suppressed in Orbit. The failure shape is a bad mapping on the CSV path, where a column you skipped quietly un-suppresses people. Verify after every contact-bearing import: E.164 phone formatting, consent state matching the source, and the segment definitions under Audience. The contacts import guide walks the verification checklist.
Recovery: three paths off the console
Starring the same console — Settings → Migrations — and the per-job row that carries status, failure reason, counters, and conflict list.
Path 1 — retry (the default). Cancel what is in flight if anything is, then re-run the wizard over the same connector. Because a fresh job always re-runs the pre-flight, a fixed upstream shows up in the new preview's counts before anything writes again. The rows the failed job already wrote are the collisions the new job's duplicate policy — skip, overwrite, or merge, set at preview — now decides on. Prefer this path when the job stopped because the upstream was stale, a credential expired, or the scope was wrong: you want the data, delivered correctly, and the reconcile counts then line up against the preview.
Path 2 — roll back (the scoped delete). When the wrong rows came in, roll back the job. Rollback deletes precisely the contacts that job created — reversible by job id, never a tenant rewind — from either the wizard or the console, within 24 hours of the job reaching a terminal state. Job data that the job merely updated stays; pre-existing contacts stay; non-contact configuration is out of scope. One rollback per job, and the rolled-back marker plus the removed count confirm it landed. Then re-run with the corrected scope or policy.
Path 3 — escalate (with identifiers, not narrative). When both loops exhaust — cancel-and-retry sticks again in queued, or the same failure reason repeats on a clean dry run — the support reply is one lookup if you bring the identifiers: the job id and request id from the console row, and the sequence you already ran. "Cancelled, waited for terminal, re-ran the wizard, new job stuck queued" tells support the retry loop is exhausted.
The Settings → Migrations console guide is the operator loop for all three paths — read it alongside this post.
The pre-flight for a retry that sticks
Before restarting anything, four checks in order:
- Confirm the scope. Uncheck the entity kinds you meant to leave behind the first time — every kind is checked by default, and a retry with the default scope re-imports data you deliberately trimmed.
- Set the duplicate policy deliberately. The failed job's partial rows are the collisions the retry now meets. Skip (the default) leaves each Orbit row as the failed job left it; overwrite replaces it; merge combines fields. The dry run reports the known-conflict count per kind — read it before starting the real run, because it is the count of rows your policy is about to decide on.
- Re-check the source against the dry run. The preview is timestamped at generation. If your Klaviyo audience or Twilio inventory moved since you connected, the ETA and the conflict count are stale — re-run the preview and use the numbers that come back now.
- Keep conflict count and ETA honest. The ETA is deliberately pessimistic — it paces to the most restrictive endpoint the import touches, so a flows-heavy Klaviyo account does not trip the upstream rate limiter mid-run. Treat it as "how long can this take at worst," not a promise; a retry that surprises you by finishing quick was the pessimism working, not a bug.
Frequently asked questions
Can I resume a failed migration where it stopped?
Not in place — a fresh run against the same source and scope is the resume. Orbit has no pause or per-step "retry failed rows" for wizard jobs; rows the failed job already wrote stay, and the new job's duplicate policy (skip, overwrite, or merge, set at preview) decides each collision with them. For CSV contact imports, failed rows come back as a downloadable skipped-rows report you fix and re-submit — that is a per-row retry.
Do I have to roll back a failed job before retrying?
No. Only roll back when the wrong data actually landed and you want it gone first. The default recovery — the job stopped before it wrote much — is cancel, then re-run. Rollback is the scoped delete: exactly the contacts that job created, nothing else, once per job.
What stays behind after a failed migration?
Exactly the rows the job managed to import before it halted — each owned by that job id, each visible under Settings → Migrations with the imported / skipped / failed counters. Outbound traffic never touches the upstream during any of this: imports are read-only on the source, and messages or calls you send from Orbit exit through Devotel Orbit's own carrier routing either way.
Why did my migration stop before anything imported?
The usual cause is a credential or export problem the wizard could not validate — the wrong Klaviyo key, a Twilio subaccount the Connect flow cannot reach, or an expired key — or a job stuck in queued because the worker lane was saturated. The dry run is the gate: re-run it, confirm counts and known conflicts come back sane, and only then start the real run.
Does a failed migration affect my live source account?
No. The wizard is read-only against the upstream — a failed run changes nothing on the source, and cut-over happens when you point your own integration at Orbit, not when any import finishes. The Klaviyo importer post makes the same guarantee in full: your legacy account keeps serving until you switch it off, on your schedule.
Published 15 September 2026.