Current Location ：
Migrating a Contact Centre to the Cloud: What Actually Moves
Contact centre migrations fail in a familiar way: the new platform is installed, the old one is switched off, and everyone discovers in the following weeks that things that worked in the old design do not work in the new one, usually because the old design was not really a design so much as accumulated behaviour. A cloud migration is not a swap of one box for another; it is a redesign of routing, reporting, resilience, and the daily habits of an entire team. This article covers what genuinely moves with the platform, what must be redesigned, and how to keep the migration survivable for the staff and the customers in the middle of it.
What Moves and What Must Be Built
The temptation is to assume that everything that exists in the current system will exist in the new one. Some things move because they are standard: queues, numbers, routing rules at a basic level. Others are behaviours that were never configured anywhere and simply reflect how people worked: quiet escalation paths, informal skills, the way a supervisor handles a difficult caller. Those behaviours have to be designed consciously in the new platform, because the platform will not preserve them by magic.
| Asset | Moves? | What it actually requires |
|---|---|---|
| Numbers and routing | Partially | Numbers port or forward; routing rules must be rebuilt and tested |
| Queues and skills | Rebuild | Designs that were implicit become explicit configuration |
| Historical reporting | Extract | Historical data does not migrate with the platform |
| Call recording | Partially | Recording architecture, storage, and retention all change |
| Integrations | Usually rebuild | CRM and telephony integrations are re-pointed, not carried |
| Staff habits | No | Training and rehearsal on the new platform are part of the project |
Routing Redesign Is the Hidden Project
Most migrations budget for platform cutover and train agents. They under-budget for routing. Moving to a new routing engine means every queue, skill, weight, and transfer rule gets rebuilt, and every one that was wrong before is now wrong in a new place with less history to explain it. The routing work is often the largest single part of the migration and the most invisible in planning documents.
- Rebuild routing against a written description of what the current system actually does, not what the team believes it does
- Reconcile every queue against its stated purpose, and retire ones nobody knows the purpose of
- Test a representative call in every queue before cutover, not after
- Plan a slow cutover where possible, rather than a single switch, so defects are visible to smaller numbers of customers
- Keep a fallback path for each queue for the first days, even if it is manual
Staff See It Before Customers Do
Agents should experience the new platform before customers do. That means training on the real queues with the real scenarios, and ideally a shadow period where agents use the new system while the old one still carries traffic. The cost of this is small compared to the cost of agents learning the platform on live calls with real customers, which is what happens when training is scheduled after cutover.
Resilience Changed, Not Just Moved
Resilience in a cloud contact centre is a different design from resilience in a premises system. The failure modes are not hardware but connectivity, licences, and third-party dependencies. Emergency calling arrangements, supervisor access, and overflow to another site all need to be re-verified against the new architecture, and the resilience plan should be tested as part of the migration, not discovered in a post-mortem.
Redstone Approach
Redstone supports on-premises and cloud-oriented contact centre deployments on the REX IP-PBX platform, including routing design, number migration coordination, recording and retention architecture, and migration planning. Our teams can help you scope what actually needs to move, redesign routing before it is forced by the platform, and structure a cutover with rehearsal and fallback. Cloud platform selection and commercial arrangements remain yours; we scope technical migration work in writing.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
