The Connect tenant is the easy part. Stand it up in a region, attach an instance, point a few flows at a Lambda. A confident engineer has a working sandbox by lunchtime. The hard part — the part that decides whether the migration ships on time — is moving the phone numbers. Not the IVR, not the agent desktop. The DIDs your customers dial. The toll-free your marketing printed on six million envelopes. The vanity number the CEO has had since 2003.
AWS publishes two pages on this — one on porting, one on claiming. Both are accurate. Neither tells you what the carrier handoff looks like in week eight when the FOC date slips, the LOA is rejected for a comma in the billing address, and the cutover weekend you booked is the weekend the losing carrier's porting desk goes dark for a public holiday in a country none of your team work in.
This is what we have learned shipping these migrations across the US, the UK, three EU countries, and Nigeria.
Key takeaways
- Porting timelines are set by the losing carrier and the regulator, not by AWS — budget six to twelve weeks per region and start the LOA the day you sign the Connect contract.
- The Letter of Authorisation is the most-failed artefact in the migration — addresses must match the losing carrier's billing record character-for-character, and a comma or company-suffix mismatch resets the clock.
- Regional regulators behave very differently — UK Ofcom is the cleanest, Germany's BNetzA and France's ARCEP have country-specific paperwork AWS support cannot file for you, Nigeria's NCC framework is uneven across carriers in practice.
- The SIP-trunk-plus-claimed-number pattern is the right answer when porting is high-risk — keep the legacy carrier as the SBC-fronted origin and port the numbers as a clean second step once Connect is proven.
- The 72-hour rollback window after cutover is undocumented and load-bearing — losing carriers will accept a port-back if you act fast, and the window is measured in days.
Porting is the migration risk teams underestimate
Every Connect migration plan we have been brought into has the same shape — a Gantt chart with six tracks for tenant build, IVR, CRM, agent desktop, reporting and training. The seventh, the carrier handoff, is either missing or compressed into a two-week box labelled "port numbers."
Numbers do not port in two weeks. A best-case US port of a clean DID block runs fifteen business days from clean LOA to FOC. A toll-free RESPORG change is twenty to thirty. A German Festnetz number leaving Deutsche Telekom takes the longest portable timeline the regulator allows. EU averages four to eight weeks. UK two to three. Nigeria is officially fast and operationally inconsistent.
The carrier handoff cannot be parallelised by adding engineers. One losing carrier, one porting desk, one regulator gating the FOC. You start the day you sign, or you start late.
The porting lifecycle, end to end
Every port follows the same five-phase shape. Names differ by jurisdiction.
One — the Customer Service Record pull. Before filing the LOA you need an authoritative record of how the losing carrier has the account on file: account number, billing address character-for-character, authorised contact, every DID on the account. US carriers release within forty-eight hours; UK within five working days; EU varies; Nigeria is operator-dependent. The CSR is the source of truth the LOA must match.
Two — the Letter of Authorisation. Signed instruction from the legal entity that owns the number, referencing the CSR exactly. Company name with the right suffix (Ltd vs Limited matters). Address character-for-character. Account number in the losing carrier's format. Wet signature from a contact named on the CSR. Eighty per cent of port rejections we have seen are LOA defects, most of them address-format mismatches.
Three — the porting request and FOC date. AWS submits to the losing carrier, which responds with a Firm Order Commitment — the moment the number actually moves. US seven to ten business days out. EU and UK two to four weeks. FOC dates slip. Carriers reject with a fault code that maps to "we need more paperwork" but reads as "we do not want to lose this account." You re-file, the clock resets.
Four — the test-call window. The hour before FOC is your last test on the legacy carrier; the hour after is your first on the new one. Between them is a fifteen-to-thirty-minute interval during which inbound may route unpredictably. Schedule for the lowest-traffic hour you can defend.
Five — the rollback path. The losing carrier holds your old configuration for a brief window after the port completes, during which an emergency port-back is possible. The single most important fact in this article and the one nobody documents. Plan for it before cutover, not after.
Regional variation breaks plans
United States — FCC LNP. Mature and well-enforced. Toll-free goes through Somos and a RESPORG (Responsible Organisation) change — a separate workflow with a different request type. Watch for ports from CLECs where the underlying provider is a different entity.
United Kingdom — Ofcom. The cleanest porting environment we have worked in. Geographic and non-geographic 03/08 numbers port reliably in two to three weeks.
Germany — BNetzA. Geographic numbers port in principle. In practice the losing-carrier paperwork is the most rigid we have seen — every field on the Portierungsauftrag is checked, the Anschlussinhaber name must match the Gewerberegister entry, a single transposed digit on the customer number triggers automatic rejection. Four to eight weeks.
France — ARCEP. The Relevé d'Identité Opérateur (RIO) code is the defining artefact. Every line has a RIO the customer requests from the losing carrier by dialling 3179. No RIO, no port. Three to six weeks. Watch for bundled offers the losing carrier requires be unbundled first — a separate two-week process.
Nigeria — NCC. Mobile portability works reasonably between the four major operators. Fixed-line porting is operationally inconsistent — the framework exists, the operational machinery at some carriers does not. We have ported in under two weeks and we have seen ports take longer than the EU.
You cannot run a multi-region migration on one porting playbook. Each jurisdiction needs its own LOA template, its own checklist, its own person who knows the carrier-side process.
Toll-free and the RESPORG transfer
US toll-free numbers live in a separate world. They are administered by Responsible Organisations registered with Somos, the entity that runs the SMS/800 database. Moving a toll-free to Connect is a RESPORG change to AWS's RESPORG — different form, different timeline (two to four weeks), different failure modes from a DID port.
The trap is that many enterprises do not know who their current RESPORG is. Toll-free numbers acquired through resellers, marketing agencies, or merged subsidiaries are often held under a RESPORG that is not the carrier the bill arrives from. We have seen migrations where the RESPORG was a defunct agency whose principal had to be located before the transfer could be authorised. Same shape applies in the UK for 0800 and across the EU — find the entity that controls the routing record, not the one that sends the invoice. Start with a Somos lookup.
SIP trunk plus claimed number — the pattern AWS does not push
The Connect docs present two options — port your numbers in, or claim new ones from AWS. There is a third. Keep your legacy carrier, claim new numbers in Connect, and use SIP trunking to bridge inbound from the legacy numbers into the Connect instance. Legacy carrier terminates inbound on a Session Border Controller you control. The SBC originates a SIP call to a Connect SIP endpoint (Amazon Chime Voice Connector is the standard pattern). Connect treats it as inbound. CRM, IVR, and agent desktop work as if the number were claimed natively.
This is the right answer when porting is high-risk (vanity, toll-free with marketing dependencies, regulated lines); when the migration is region-by-region and you want to run a hybrid while sequencing port waves; when the legacy carrier has bundled services that make a clean exit impossible; or when the losing carrier is slow (Germany, parts of the EU, some Nigerian fixed-line situations).
The trade-offs are honest. You pay both carriers. You operate an SBC. The latency budget includes one extra SIP hop. What this pattern buys is decoupling — you prove Connect with low-risk numbers, port at your own pace, and always have a clean rollback because the legacy carrier never went anywhere.
The 72-hour rollback window almost nobody plans for
This is the section the AWS docs do not write. After a port completes, the losing carrier holds the original routing configuration for a brief window — seventy-two hours in the US, longer in some EU jurisdictions, sometimes shorter in Nigeria. During that window an emergency port-back is possible. After it, a port-back becomes a fresh port in the other direction with full timelines and full paperwork.
The window matters because Connect cutovers go wrong in ways that are not visible immediately. The number ports. Test calls succeed. Three hours of production look fine. Then a Friday-afternoon surge surfaces an IVR routing bug, an SBC certificate expiry, a Lambda permission that worked in test and not in production. Now you have a choice — fix forward under pressure on a contact centre that is offline, or roll back.
If you have planned the rollback it looks like this. An unsigned emergency LOA pre-filled with the original details. A verified contact for the losing carrier's porting desk with their emergency port-back process documented in advance. A decision criterion in the runbook for rollback versus fix-forward — and that decision lives with a named human, not a committee.
If you have not planned the rollback, the window passes while you debug, and the option is gone before you reach for it. We have seen this twice. Both times the team felt the same way afterwards — "we did not know we had that little time."
What goes wrong, in production
The vanity-number conflict. Mid-port, marketing discovers a print campaign three weeks out using the number in flight. The carrier cannot pause without re-filing. Resolution is usually the SIP-trunk fallback retroactively — legacy holds inbound until the campaign closes, then the port completes.
The carrier holiday calendar. Most losing carriers have one porting-desk team observing their local public holidays. A cutover scheduled for the Friday before a four-day public holiday in the losing carrier's country means the FOC lands on a day with no human cover. Test-call failures become unrecoverable for four days.
The "porting black hole." Between LOA acceptance and FOC confirmation, status from the losing carrier is opaque. Connect's porting page may show "in progress" with no detail for days. This is normal. The silent week is the normal week.
The number that ports half-way. Losing carrier completes the port in their systems, gaining carrier in theirs, and somewhere between, a routing record in a third-party transit network is wrong. The number rings on neither side. Fix requires both carriers to coordinate via the transit network — one-to-three business days.
The LOA that fails on Ltd vs Limited. Real example. CSR shows "Acme UK Limited." LOA shows "Acme UK Ltd." Port rejected with a code that mapped, eventually, to "company-name mismatch." Two weeks lost.
The cutover runbook items vendors do not write
The Connect deployment guide tells you how to claim a number, configure a flow, attach a queue. It does not tell you what to put in the cutover runbook.
T minus 7 days. CSR and LOA reconciliation signed off by the legal-entity contact. FOC confirmed. Cutover window booked with operations. Rollback LOA pre-filled. Losing carrier's emergency porting-desk contact verified by phone. SBC tested if SIP fallback is in scope.
T minus 24 hours. Final test call on the legacy carrier. Connect flow walkthrough with the operations lead. CRM smoke test. Lambda permissions verified in production. Final FOC confirmation, with a call to the porting desk to confirm a human is on duty.
Cutover window. Person on the bridge with a stopwatch. Test phone with a SIM on a different carrier — you are testing inbound from a true external network. Success criteria — ringback, IVR audio, agent answer, hangup tone. Failure criteria and the named decision-maker for rollback. Active monitoring of inbound volume so you see a drop before customers complain.
T plus 2 hours. Test-call cadence every fifteen minutes for two hours, every hour for the next six. Reporting reconciliation between the legacy ACD's last hour and Connect's first hour.
T plus 72 hours. The rollback window closes. Clean, you have shipped. Failed forward into something you cannot fix, the next decision is now an order of magnitude more expensive.
What this teaches us about Connect migrations
The Connect migration is two engagements in parallel. One is a cloud build — tenant, flows, integrations, agent desktop. The other is a telecoms project — carrier handoffs, regulatory paperwork, FOC dates, rollback windows. AWS is the right vendor for the first. AWS is one of the parties in the second, not the gating one. The losing carrier is gating. The regulator is gating. Your legal-entity records are gating. Your runbook is gating.
Teams who ship cleanly start the LOA the day they sign the Connect contract, not the week they finish the IVR. They keep a SIP-trunk fallback in their pocket for the highest-risk numbers. They write the rollback runbook before the cutover, not after. They treat the carrier handoff as a programme of work in its own right.
The Connect tenant gets the headlines. The numbers carry the calls.
FAQs
How long does it actually take to port a number into Amazon Connect?
The Connect-side workflow is days. The carrier-side timeline runs from two weeks in the UK to four to eight weeks in Germany and France, with US ports typically landing in five to fifteen business days. Toll-free RESPORG transfers in the US run two to four weeks. Nigeria varies. The right rule of thumb is six to twelve weeks per region, end to end.
Why does the Letter of Authorisation keep getting rejected?
Eighty per cent of LOA rejections we have seen are character-for-character mismatches against the losing carrier's Customer Service Record — wrong company suffix (Ltd versus Limited), address punctuation, account number formatted differently, or a signature from someone not on the CSR. The fix is to pull the CSR first and copy every field verbatim into the LOA.
When should we use a SIP trunk into Connect instead of porting the numbers?
Use the SIP-trunk-plus-claimed-number pattern when porting is high-risk — vanity numbers, toll-free with revenue dependencies, regulated lines, or jurisdictions with slow porting. The cost is paying both carriers and operating an SBC. The benefit is decoupling — you prove the platform, port at your own pace, and always have a clean rollback.
What is the rollback window after a port completes, and how do we use it?
Most losing carriers will accept an emergency port-back for around seventy-two hours after the port completes, longer in some EU jurisdictions. To use it you need a pre-filled rollback LOA, a verified contact for the losing carrier's porting desk, a documented decision criterion for rollback versus fix-forward, and a named human empowered to call it. After the window closes, a port-back becomes a fresh port with full timelines.
How do toll-free numbers differ from regular DIDs in a Connect migration?
US toll-free numbers are administered by Responsible Organisations via the Somos SMS/800 database, not by carriers in the same sense as regular DIDs. Moving a toll-free to Connect is a RESPORG change to AWS's RESPORG. The common surprise is that the current RESPORG is not always the carrier that sends the invoice — toll-free acquired through resellers, agencies, or subsidiaries often has a RESPORG of record nobody on the current team knows about. Start with a Somos lookup.
Companion content
- Legacy Contact Centre to Amazon Connect — Migration Playbook
- Amazon Connect AI Agent: What Ships, What You Build
- Building AI Agents on Amazon Bedrock — Foundations
- Identity-First AWS Migration for Nigerian Banks
- Bedrock Pipeline — Client Case Study
How to engage
If your team is scoping a Connect migration and the carrier-handoff track has not been planned yet, that is the right week to talk to us — before the LOA paperwork starts and the cutover window gets booked. Talk to us at creativeminds.dev/contact.