Migrating as is: paying for the cloud to stay in legacy.

Iso-functional migration is not neutral. It does not just move flows. It also moves habits, exceptions, and rules that have become opaque.

The comfort is real at the start. You keep the same screens, the same queues, the same routing. But the bill changes fast, because the cloud runs faster a logic that has not been reset.

The problem is not the technology. The problem is the mechanical preservation of an old model. A new platform does not fix vague decisions. It only makes them more visible, more expensive, and more durable.

The trap of false simplicity

The message sounds reassuring. Same scope, same organization, same routing. The project moves forward without open conflict, and everyone feels the risk is contained.

This simplicity is misleading. It avoids hard trade-offs and pushes back the sorting of uses. Queues created for a one-off need stay active. Inherited skills survive. Routing exceptions become de facto rules.

The cloud does not clean anything up on its own. It industrializes what you give it. If the business logic is not reviewed before cutover, it hardens into a more modern base, but just as cluttered.

Ask the vendor or integrator: "Can you show me the full list of queues, skills, and routing rules, with their usage over twelve months?" Demand a dated export, not a summary table. An object with no measurable traffic, or less than 1% of interactions, deserves an explicit decision.

Also check a common trap: the queue kept "for safety" when it is only used for manual fallback. The symptom is simple: no one can say who activates it, or within what delay. This grey area often ends as permanent debt.

Sorting before cutover

The right approach is not a full redesign. It is sorting. Every queue, every skill, every rule must have an identified business owner and a reason to exist.

Without an owner, the rule becomes orphaned. Without a reason, it becomes legacy. That is how workarounds move from one project to the next, then multiply in the new base.

The sorting must stay binary. Migrate, merge, or remove. As soon as a fourth option appears, such as "we will see later," debt enters the scope and rarely leaves the project.

Ask: "Who signs off on keeping this queue, and who accepts its removal?" Ask for a named person, not a generic role. A verifiable criterion can be written into the contract: no rule goes live without a business owner, a decision date, and a retention reason.

The classic trap is the rule kept because it "might be useful." The symptom is a catalogue that grows without any drop in active volume. The more unresolved objects you keep, the more the migration becomes a simple copy of the legacy.

Real volume, not assumed volume

Teams often overestimate the importance of inherited structures. A queue looks critical because it has existed for a long time. A routing path seems sensitive because it survived several reorganizations.

The only useful judge is real traffic. Twelve months of volumes give a more reliable reading than internal impressions. They reveal duplicates, dead ends, seasonal peaks, and exceptions that have become normal.

Low volume does not mean automatic removal. It may hide a backup queue, a regulatory use, or seasonal activity. But it requires written justification and clear business validation.

Ask for historical exports by queue, by skill, and by rule. "Can you provide monthly volumes, peaks, and quiet periods over twelve months?" Demand a reconciliation between observed traffic and assumed traffic. If the gap exceeds 20%, the rule must be reviewed again.

The trap is the "historic" queue everyone believes is critical. The symptom is low volume, but strong fear of touching it. That fear often signals a poorly documented dependency, not real criticality.

The hidden cost of configuration debt

Configuration debt does not look like a failure. It looks like a pile-up of micro-decisions. Each setting seems acceptable, then the whole thing becomes opaque.

The more inherited the base, the more expensive each change becomes. A simple modification then needs several approvals, several tests, and several exceptions. The modern platform loses its edge, because it carries logic that is too dense to stay readable.

The cloud does not fix legacy. It bills it faster.

The right indicator is not the number of migrated features. It is the number of rules that are justified, maintainable, and assigned. If that number is not measured, complexity has already taken over.

Ask the integrator: "What is the maximum threshold of rules per queue, and how do you control it?" Put a verifiable contractual criterion in writing: any rule without an owner, without an associated test, or without change documentation is rejected in acceptance testing. The trap here is a configuration that works, but that no one dares to change. The symptom is a change lead time that keeps growing with every request.

What to demand before migration

I look for three proofs. A complete inventory. A business owner for each object. An explicit decision for every queue, skill, and rule.

Without those three elements, the migration copies the existing setup. With them, it becomes sorting. The difference shows before detailed design, not after go-live.

Ask for a single table with three columns: migrate, merge, remove. Add real volume, owner, and justification. "Can you deliver this table before design freeze?" Reject any line without a signed decision.

Also demand a clear exit criterion: no cutover until 100% of objects have a status, an owner, and a review date. The final trap is the "to be handled later" batch, which grows until it becomes the new reference debt.