The new contact center goes live on Monday. Calls connect. The queues work. Agents can sign in, and the project team closes the launch checklist.

Then a customer calls about a refund. The agent still needs approval from a separate team, still sends an email to request it and still cannot say when the money will arrive. The technology is new. The delay is familiar.

That situation illustrates a decision every migration team faces: which parts of the existing service should move unchanged, and which need to be redesigned before they become embedded in the new setup?

Find the delay behind the contact

The refund journey is a useful starting point because it has a clear purpose and a visible endpoint. The customer wants the correct amount returned. Answering the call is only one step.

Follow a sample of requests from the first enquiry to completion. Look at where agents search for information, which approvals are required and how pending work is tracked. Ask what happens when an approver is unavailable or the original request contains an error.

The delay may sit outside the contact center. If finance owns the next action, a faster queue cannot remove that dependency. The migration needs a decision about ownership, authority or the exchange of information before configuration can help.

Make a deliberate choice about what moves

Replacing an ageing platform can be necessary for reliability or supportability. Waiting to perfect every process can expose the organization to a different risk: an essential replacement that never finishes.

A practical migration therefore separates required continuity from selected service improvements. Preserve what must work on day one. Choose a limited number of journeys where the redesign is understood well enough to deliver alongside the move.

For the refund request, that could mean an approved request form, a shared status and a defined escalation when work is overdue. The platform then supports an agreed way of working. It does not have to resolve every organizational dependency through software.

Record the processes that are intentionally being carried forward. Give unresolved issues owners and review dates so temporary compromises do not quietly become permanent.

Test the request, then test the platform

Technical testing confirms that calls route and systems exchange information. Service testing should also follow the refund to its conclusion.

Can the agent explain the current status? Can the receiving team identify the requested action? Does the customer receive an accurate confirmation? What happens if the transfer fails?

After launch, compare the same types of requests with the earlier baseline. Look for repeat contacts, overdue work and completed refunds alongside platform stability.

The customer will never see the migration checklist. The change becomes meaningful when a familiar problem is easier to finish.