CPQ to Revenue Cloud, and the migration nobody scoped

The statement of work says CPQ to Revenue Cloud Advanced. Eight months, a partner, a phased cutover by product line.

What the team finds in week 3 is different. There are 200 price rules, and roughly 60 of them are load-bearing in ways that only reveal themselves when you turn one off. There's custom Apex on QuoteLineItem written by a contractor whose company no longer exists. There's a renewals process built by an SI in 2020 that Finance has quietly built three downstream reports against. And there's a quote document template that looks cosmetic right up until Legal explains that the ordering of the terms section is a compliance requirement.

None of that was in the scope. All of it is in the way.

The asymmetry

Every migration has the same shape. The target is well documented, because it's new and the vendor wants you to succeed on it. Revenue Cloud Advanced has a data model, a migration guide, and a partner ecosystem that has done this before.

The source is not documented. It was documented once, in a Confluence space, in 2020, by someone who has since left. Since then, it has absorbed 6 years of business change delivered as configuration, and configuration doesn't come with a changelog anyone reads.

So the project splits into two unequal halves. The half you scoped, which is building the new thing. And the half you didn't, which is working out what the old thing actually does. In most migrations, the second half consumes the majority of the hours and all of the schedule risk.

The discovery work is also the part your SI bills the most for, which is worth knowing when you look at the invoice.

What "actually does" means in practice

Three specific gaps open up between the implementation and the description of it.

Behavior that diverged from intent. A price rule was built to apply a volume discount above 500 units. Someone later added a condition excluding one product family, for a deal that closed in 2022. The rule still carries the exception. Every quote for that family has been priced slightly differently for four years, and nobody flagged it because nobody was comparing.

Logic that lives in the wrong place. The approval threshold isn't in the approval process. It's in a formula field feeding a validation rule that nobody thinks of as pricing logic. Migrate the approval process cleanly, and you'll still lose the threshold.

Workarounds that became load-bearing. A field originally added as a temporary flag during a 2021 data cleanup is now read by two integrations and a Tableau dashboard the CRO looks at weekly. It has no description. Its API name is Temp_Flag_2__c.

The documentation will show you none of these. Only the org will, and reading a large org by hand is what makes migrations expensive.

What Tribal does with it

Tribal reads both sides of the migration.

On the source side, it maps what the current implementation actually does. Every price rule, every piece of Apex, every field and the things that read it, every automation that fires and in what order. Including, specifically, the parts that diverge from how anyone describes them. That's the deliverable that used to be a two-week discovery engagement.

On the target side it generates the architecture for the new product using your real business logic as the input rather than a generic reference model. Then it builds it, generates the tests, and simulates the impact against the rest of the org before anything deploys.

The business logic survives the move. The workarounds get left behind, and you get a list of what was dropped and why, which is the artifact that makes the cutover conversation with Finance short instead of long.

"With Tribal, we move significantly faster, iterating quickly and deploying to production with confidence. We're now able to better serve users in 19 countries while streamlining how they work with data across both new and existing markets." Nir Rehav, CIO, Adama

The migration that landed this year

There's a newer version of this problem, and it has a shorter runway.

If you built Agentforce agents in 2025, you built them on topics, actions, and prompt instructions. Behavior was shaped by natural language guidance and tuned by iteration. It worked, mostly, and where it didn't work, you added another instruction.

AgentScript changes the model. It's a typed, structured language where you declare when the agent reasons with an LLM and when it follows deterministic logic, which subagents it can call, and what guardrails constrain it. That's a better foundation, and it's now GA and open sourced.

It's also a migration, with all the same properties as CPQ to Revenue Cloud.

Your service team spent a year tuning those instructions. The refund threshold, the escalation path for enterprise accounts, the specific phrasing that stopped the agent from over-promising on delivery dates, the topic boundary that keeps billing questions away from the support agent. That knowledge lives in prompt text and in the heads of two people, and it has to survive translation into typed logic.

Nobody wrote it down. Nobody ever does.

The same approach applies. Read what the current agents actually do, including the behavior that emerged from iteration rather than design, then generate the AgentScript equivalent with guardrails made explicit, and validate before it ships. The advantage of doing it now is that the 2025 agents are still small. The advantage of doing it with a map is that you don't lose the year of tuning.

Platform migrations are the same motion

Two orgs after an acquisition. A move onto a new system of record. A ServiceNow instance being pulled back toward out-of-box after years of custom scripting.

Larger scale, identical structure. The work is dominated by understanding what already exists, and that's the part a live metadata map takes off the critical path.

Which changes how you scope. When discovery takes hours, the migration stops being a bet on whether your partner's estimate holds and becomes a project with a known blast radius, a documented cutover, and a list of what you chose to leave behind.

That's a different conversation to have with your steering committee.