An infrastructure line item shows up in the value-creation plan, someone calls it a cloud migration, and a budget request lands in front of the operating partner. The number is real. The commercial case is often not. Most migration proposals arrive framed as a technical project with a technical justification, which is exactly the framing that lets spend expand without a corresponding movement in EBITDA, integration speed, or exit readiness. The operating partner’s job is not to approve or reject the migration. It is to force the proposal into the language of enterprise value before a dollar moves.

This guide is for the operating partner or portfolio company executive who owns that decision inside a PE-backed business, and who needs to judge a cloud migration for a portfolio company the way they would judge any capital allocation: against a baseline, an owner, and a defined return. It assumes budget, not education.

1. Start with the commercial trigger, not the technology

A migration is worth funding when a specific business event depends on it. The common triggers are concrete: an add-on that cannot be integrated because two companies run incompatible on-prem stacks, a data center lease renewal that forces a build-or-move decision, a system nearing capacity that is capping revenue, or a diligence finding that flagged infrastructure as a hold on the thesis. When the trigger is real, the migration has an owner and a deadline. When the trigger is “the platform is old,” the migration is an engineering preference wearing a business costume.

The first question the operating partner should ask is which board-level outcome the migration serves. If nobody can name one, the project is not ready for capital.

2. Tie the migration to one of five value levers

Migrations that survive scrutiny usually map to a lever the deal team already tracks. Force the proposal onto one of these:

• EBITDA expansion through retired data center leases, reduced licensing, or fewer infrastructure staff redeployed to higher-value work.
• Faster integration of add-ons onto a shared platform, which is where much of the buy-and-build thesis actually gets won or lost.
• Revenue enablement where the current stack is capping transaction volume, uptime, or the ability to ship features customers pay for.
• Reduced operating risk from end-of-life hardware, single points of failure, or a security posture that will surface again at exit.
• Management visibility where fragmented systems make consolidated reporting and forecasting unreliable.

Bain’s annual private equity report has repeatedly tracked the shift toward operational value creation as multiple expansion becomes harder to rely on. A migration that touches one of these levers has a place in the value-creation plan. A migration that touches none of them is deferred maintenance.

Classify the impact honestly. A retired lease is realized savings. A faster add-on integration is enabled value that only becomes real when the next deal closes. Do not let enabled value read as money already in the bank.

3. Establish the baseline before anyone proposes a target state

No migration should be scoped without a documented current-state cost and risk baseline. That means the fully loaded cost to run today: hardware, facilities, licensing, staff time, and the cost of incidents and downtime over the trailing twelve months. Without this number, the migration has nothing to be measured against, and post-migration “savings” become a story rather than a variance against plan.

This is the same discipline that governs any embedded technical engagement inside a portfolio company. If the operating partner has read the technology due diligence findings from the deal, the baseline should reconcile to what that diligence already surfaced. A migration proposal that contradicts diligence, or ignores it, is a signal that the two teams are not talking.

4. Choose the migration approach on economics, not fashion

The approach dictates cost, timeline, and how much value the migration actually unlocks. The operating partner does not need to design the architecture, but does need to understand the trade-off being made.

Rehost, replatform, or rebuild

A lift-and-shift rehost is fast and cheap to execute but often carries the old cost structure into the cloud, which is why some migrations produce a higher bill and a disappointed CFO. A replatform captures more savings by using managed services. A full rebuild captures the most value and costs the most time and money. The right answer depends entirely on the trigger from section one. An add-on integration deadline argues for speed. A revenue-capping system nearing capacity may justify the rebuild.

The cost trap to watch

Cloud spend is easy to start and hard to control. If the proposal has no plan for cost governance after go-live, assume the run-rate will drift above the business case. McKinsey’s research on cloud economics has consistently found that promised savings depend on operating model changes, not just the move itself.

5. Assign one accountable owner and a real decision right

Every migration needs a single accountable owner inside the portfolio company, with the decision right to trade scope for time. When the owner is “the vendor” or “IT,” accountability evaporates at the first slipped milestone. The operating partner should name this person before funding, and that person should report status against plan at the board cadence, not on request.

This is the same governance failure pattern that shows up when RevOps integration stalls after a merger: the synergy exists on paper, but no one owns the dependency that unlocks it. Infrastructure migrations fail the same way, quietly, one deferred cutover at a time.

6. Sequence the migration against the deal calendar

Timing is a commercial decision, not just a technical one. A migration scheduled during the first 100 days competes for attention with integration, quick wins, and management assessment. A migration scheduled in the run-up to a sale process risks disrupting exactly the systems a buyer’s diligence will examine. Neither is automatically wrong, but the sequencing has to be deliberate.

The safest windows are usually after the operating rhythm is established but well before the exit clock starts, when there is time to prove the new state is stable and the savings are real in the numbers a future buyer will inspect.

7. Build the risk register the operating partner will actually review

A migration risk register belongs in front of the operating partner, not buried in a project plan. It should name the data migration risk, the cutover downtime exposure, the rollback plan, the dependency on key staff, and the security and compliance implications. If the portfolio company operates under accessibility or regulatory obligations, the migration is a moment where those can break, which is why the same rigor applied to accessibility compliance engineering should apply here.

The Harvard Law School Forum on Corporate Governance has published extensively on how cyber and operational risk now sit squarely in the diligence and oversight remit, not the IT department’s private domain.

8. Decide who executes: internal team, generalist firm, or embedded specialist

The build-versus-buy decision on execution capacity is where cost overruns are made or avoided. An internal team that has never run a migration will learn on the portfolio company’s budget. A large generalist consultancy brings process and a large invoice. An embedded specialist that runs migrations repeatedly across similar companies brings a playbook.

The judgment framework is the same one used to evaluate any operating-partner-facing advisory firm: does the provider quote outcomes tied to the business case, or hours tied to activity? The same lens applies when deciding whether to outsource an operational function at all. Buy the outcome, not the timesheet.

9. Refuse to buy activity dressed as progress

The clearest failure mode is a status report full of tickets closed, servers provisioned, and hours logged, with no line connecting any of it to the value lever from section two. Milestones, tickets, and sprints are the vendor’s internal register. They are not evidence that the migration is delivering.

The same discipline the operating partner would demand when hiring a sales operations consultant without buying activity applies here: every status update should restate progress against the business case, not the task list. PitchBook and Preqin data on operational value creation both point to the same conclusion, that the funds pulling ahead are the ones measuring outcomes, not effort.

10. Set the go-live and post-migration verification standard

The migration is not done at cutover. It is done when the baseline from section three has been beaten in the actual numbers, the run-rate cloud cost is under governance, and the risk register items are closed. The operating partner should require a post-migration review that compares actual against plan on cost, timeline, and the named value lever. If savings were forecast and did not materialize, that is a finding, not a footnote.

11. The operating partner’s decision checklist

• Is there a named commercial trigger with a deadline, or is this deferred maintenance?
• Which of the five value levers does this migration move, and is the impact realized, enabled, or forecast?
• Does a documented current-state cost and risk baseline exist, and does it reconcile to diligence?
• Is the rehost-versus-rebuild approach justified by the trigger, and is there a cloud cost governance plan?
• Is there one accountable owner with the right to trade scope for time?
• Is the timing deliberate against the deal calendar and the exit clock?
• Is the risk register in front of the board, with a rollback and cutover plan?
• Does the execution partner quote outcomes, not hours?
• Is there a post-migration review that measures actual against plan?

If any answer is missing, the proposal is not ready for capital. Send it back with the specific gap named, and the migration will come back stronger or quietly disappear, which is itself a useful outcome.

Next step

If a migration proposal is sitting in the value-creation plan and it reads as a technical project rather than a value case, have it stress-tested against the business it is supposed to serve. Review how DevriX and GrowthShuttle structure embedded technical value creation for portfolio companies and bring the proposal into the language of enterprise value before you fund it.