Introduction: The promise and reality of portfolio standardisation
The logic is compelling. A PE firm or multi-brand group with six portfolio companies is probably paying six separate Microsoft enterprise agreements, running six different backup solutions, and negotiating individually with the same three systems integrators. Consolidate that spend, share the expertise, build common capabilities, and the portfolio becomes stronger than the sum of its parts.
This is a real opportunity. Portfolio technology standardisation, done well, delivers meaningful cost savings, operational leverage, and the kind of data visibility across a portfolio that makes allocation decisions sharper. The problem is not the goal. The problem is how it typically gets pursued: with mandates, platform convergence ambitions, and governance frameworks that are too heavy for the companies they are supposed to serve.
This article is about separating the genuine standardisation opportunities from the expensive distractions, and providing a phased approach that delivers value without the destruction that usually accompanies overreach.
Where standardisation genuinely helps
Shared services: security, identity, and infrastructure
The highest-value, lowest-disruption standardisation targets sit below the application layer. Shared security operations, centralised identity management, common cloud infrastructure, and pooled DevOps capability can be adopted by portfolio companies without changing how they run their businesses day to day.
Security is the most compelling case. Most mid-market portfolio companies are running security postures that were adequate three years ago. The threat landscape has changed faster than their internal security investment. A shared security operations capability, either an internal function or a managed service procured at portfolio scale, raises the baseline across every company in the portfolio simultaneously. The per-company cost is lower than individual procurement. The capability level is higher than any single company would justify on its own.
Centralised identity management across portfolio companies, particularly for corporate users, enables cost reduction, better security controls, and simplified IT administration. It also creates the foundation for talent mobility across the portfolio, which is a genuine talent retention and development benefit.
Vendor leverage: aggregating spend for better terms
This is usually the fastest path to measurable portfolio-level value, and it is consistently underutilised. Most PE portfolios are negotiating major vendor contracts company by company, at sub-scale volumes. Aggregating that spend creates significant leverage.
The practical mechanics: map vendor relationships across the portfolio and identify overlap. Enterprise software licences, cloud infrastructure spend, major SaaS platforms, and systems integrator relationships are the first places to look. Contracts approaching renewal are the immediate opportunities. Negotiate enterprise or portfolio-level agreements that provide volume-based terms to all portfolio companies, with individual companies retaining operational autonomy over how they use the platforms.
The savings on a well-managed portfolio vendor consolidation are typically 15 to 25 percent on affected vendor spend. On a portfolio of meaningful scale, that is material. And it does not require a single platform migration or any operational disruption.
Data visibility: consistent reporting without platform convergence
One of the most valuable things a portfolio-level technology initiative can deliver is comparable data across companies. The ability to benchmark conversion rates, customer acquisition costs, fulfilment economics, and digital channel performance across the portfolio is enormously valuable for capital allocation decisions, identifying best practices, and assessing management quality.
This does not require everyone to use the same systems. It requires agreed definitions of the metrics that matter, standard extraction formats from whatever systems each company runs, and a central data layer, usually a portfolio-level data warehouse or BI platform, that aggregates and normalises. The investment is in the data layer and the definitions, not in migrating source systems.
Done well, this creates a portfolio intelligence capability that most PE firms genuinely do not have. Done badly, it becomes a reporting burden that consumes technology teams at portfolio companies without producing usable insights.
Knowledge sharing and talent mobility
The softer but significant benefit of portfolio-level technology standardisation is the community it creates. Technology leaders across the portfolio share a common set of challenges: managing vendor relationships, building capability, navigating digital transformation, integrating acquisitions. Creating a structured forum for that community to share experience produces real value.
A quarterly portfolio technology council where company CTOs compare notes on platform decisions, vendor performance, and implementation lessons is low-cost and high-value. Internal talent mobility, the ability to move a skilled engineer or product manager from one portfolio company to another for a specific initiative, is a genuine competitive advantage in a tight talent market. These benefits are available without any platform standardisation.
Where standardisation creates friction
Forcing platform convergence too early
This is the most expensive mistake in portfolio technology strategy, and it is surprisingly common. The logic appears sound: if all portfolio companies were on the same commerce platform or ERP, integration would be simpler, vendor leverage would be stronger, and talent could move between companies more easily.
The reality is different. Forcing portfolio companies onto a common platform before they are ready, or when a common platform is not actually the right fit for each company’s scale and market position, causes enormous disruption with limited upside.
A startup-stage portfolio company with 50 staff needs a very different technology stack to a mature retailer with 800. Forcing both onto the same platform either over-engineers the small company, creating unnecessary complexity and cost, or under-serves the large one, constraining capability it genuinely needs. The migration itself consumes the technology team’s capacity for 12 to 18 months, during which time the business is not using technology to create commercial advantage. The costs are direct, large, and often underestimated at the point of decision.
One-size-fits-all governance
Governance frameworks designed for the most complex company in the portfolio will suffocate the least complex one. A formal architectural review process, a mandatory security certification programme, and a quarterly investment committee cadence might be entirely appropriate for a mature, regulated business. For a fast-growing startup, the same framework is a tax on velocity that produces resistance and workarounds.
Governance that is not calibrated to the maturity and context of individual portfolio companies will be gamed or ignored. When that happens, the governance framework produces compliance theatre rather than actual oversight, which is worse than having no framework at all.
Underestimating migration costs
When portfolio standardisation requires platform migrations, the cost estimates presented at the point of decision are almost always too low. Not because people are being dishonest, but because the full cost of migration is genuinely difficult to estimate upfront.
The costs that get underestimated consistently: data migration complexity, particularly when source data quality is poor. Integration rebuild costs when the new platform has a different API model. Retraining costs for operational teams whose workflows are embedded in the old system. Lost productivity during transition, which is real even when the migration goes well. And most significantly, opportunity cost: the technology team’s capacity is fully consumed by the migration, which means no commercial innovation for the duration.
A migration that looks like a 6-month, two-million-dollar project frequently lands at 14 months and significantly more. The delta between estimate and actual is what kills the business case.
A phased approach
Phase 1: Assess the landscape (months 1 to 3)
You cannot standardise what you do not understand. The first step is a structured technology assessment across the portfolio: platform inventory, integration landscape, technical debt levels, team capability, vendor contracts and renewal dates, and data architecture. This is not a perfunctory review. It takes genuine effort to understand what each company actually has, how it is configured, and what the dependencies are.
The output of the assessment is a portfolio technology map that enables prioritisation. Where is there genuine duplication? Where are the contracts approaching renewal? Where are the highest security risks? Where is technical debt creating genuine business risk? Where is there capability that other portfolio companies could benefit from knowing about? These answers determine where standardisation investment is warranted.
Phase 2: Quick wins through vendor consolidation (months 2 to 6)
Vendor consolidation can begin before the full assessment is complete, because the opportunity identification is straightforward. Map vendor overlap from the platform inventory. Identify contracts approaching renewal in the next 12 months. Aggregate the combined spend across the portfolio and approach vendors with a portfolio-level negotiation.
This phase is the one that typically self-funds the broader standardisation programme. The savings from enterprise-level agreements across cloud infrastructure, major SaaS platforms, and systems integrator retainers can be substantial. They are also largely uncontroversial: portfolio companies keep their existing platforms and get better pricing. There is no disruption, no migration, and no governance overhead. It is purely additive value.
Phase 3: Introduce shared services selectively (months 6 to 12)
Shared services should be introduced where there is genuine duplication, clear value, and willingness from portfolio companies to adopt them. The last point matters. Mandated shared services that portfolio companies did not choose create resentment and compliance without adoption.
The highest-value shared services to consider are: shared security monitoring and operations, a centralised identity management platform for corporate users, a common data platform that enables portfolio-level reporting, and pooled specialist capability, such as a central data engineering team that supports multiple portfolio companies on a shared-services basis.
Each service needs to demonstrate value to the portfolio companies using it. If adoption requires mandate rather than genuine utility, the service is not ready to launch.
Phase 4: Establish governance and reporting frameworks (months 6 to 18)
Lightweight governance can run in parallel with the shared services build. The goal is to establish the framework that enables ongoing portfolio-level technology decisions without creating bureaucracy that portfolio companies resist.
A portfolio technology council meets quarterly. Its scope is standards, shared services, and major investment review. Its authority is advisory for most decisions, with binding authority only for security standards and data governance requirements where there is genuine portfolio-wide risk. Company CTOs retain operational autonomy for platform, team, and delivery decisions.
Alongside governance, introduce standardised technology health metrics across the portfolio. Not because you intend to mandate uniform metrics, but because comparable measurement enables portfolio-level intelligence and informs capital allocation decisions.
Governance models that work
The portfolio technology council
The council should include the portfolio CTO or operating partner representative, company CTOs, and ideally a commercial representative from the fund. Quarterly cadence works for most portfolios. Composition at the company level should reflect authority: if company CTOs do not have meaningful decision-making power, replacing them with IT managers produces a governance forum that cannot make decisions.
The agenda should be half sharing and learning, half actual decisions. If the council is purely a reporting exercise, technology leaders will stop prioritising attendance. The value of the forum is the peer interaction and collective problem-solving, not the formal governance.
Guardrails, not mandates
There is a meaningful difference between setting architectural guardrails and mandating specific technology choices. Guardrails define the boundaries within which portfolio companies make their own decisions. Mandates specify the decisions they must make.
Examples of appropriate guardrails: all portfolio companies must maintain a minimum security baseline (defined). API integrations must use documented, versioned interfaces. Customer data must be stored in compliant jurisdictions. These enable autonomy within defined risk boundaries. They generate much less resistance than mandates like “all portfolio companies must use Platform X by 2026” because they respect operational autonomy while managing genuine portfolio-level risk.
Balancing autonomy and alignment
A practical framework: standardise at the portfolio level where there is a genuine portfolio-level benefit, such as security standards, vendor negotiations, and data definitions. Leave operational decisions to the people closest to the business: platform selection, team structure, delivery methodology, and commercial technology priorities.
The test for whether a decision belongs at the portfolio level is simple: does the portfolio benefit from consistency here, or does it benefit from each company making the best decision for its specific context? For security baselines, consistency creates genuine portfolio benefit. For commerce platform selection, context matters more than consistency.
Measuring portfolio technology health
A consistent assessment framework
A lightweight but consistent framework for assessing technology health across portfolio companies enables comparison, prioritisation, and informed capital allocation. The dimensions to assess: platform currency (how current and supported are the core platforms), technical debt levels, integration maturity, team capability, security posture, and delivery velocity.
Assessment does not require every company to score identically on each dimension. It requires that the assessment methodology is consistent so that scores are comparable. A company scoring poorly on technical debt is a candidate for investment or remediation. A company scoring well on delivery velocity is a source of best practice for others.
Leading indicators vs lagging indicators
Most portfolio-level technology reporting focuses on lagging indicators: incident counts, project delivery outcomes, cost. These tell you about problems that have already occurred.
Leading indicators are more valuable for portfolio oversight: deployment frequency, technical debt trend over time, team retention, and test coverage. A portfolio company with declining deployment frequency and increasing technical debt is heading toward a delivery crisis, even if the lagging indicators look fine today. Catching it early is significantly cheaper than managing it after the crisis arrives.
Using health metrics to guide investment
Portfolio technology health metrics, applied consistently, become a genuine input into capital allocation decisions. A company scoring consistently poorly on security posture is carrying risk that needs to be priced. A company with high technical debt and low delivery velocity needs a remediation investment before it can absorb a digital transformation programme. A company scoring well across all dimensions is a candidate for innovation investment because the platform can support it.
This discipline separates PE firms that use technology health as a genuine value creation lever from those that treat it as an operational footnote.
Conclusion: Standardise the outcomes, not the tools
Effective portfolio standardisation focuses on shared outcomes: visibility, security, cost efficiency, delivery quality. These outcomes can be achieved across a portfolio of companies running different platforms, at different maturity levels, in different markets.
The temptation to mandate platform uniformity usually reflects a preference for administrative simplicity over genuine value creation. Uniform platforms would be administratively convenient. They would also be operationally disruptive, expensive to achieve, and frequently wrong for individual companies whose commercial context differs.
The connective tissue that makes a portfolio more than the sum of its parts is shared intelligence, shared services where there is genuine duplication, shared vendor leverage, and shared governance that manages portfolio-level risk without stifling commercial velocity. That is worth building. Platform uniformity for its own sake is not.
What to read next
If you found this useful, these related pieces go deeper on specific aspects:
- The retail operating model nobody talks about addresses the company-level operating model changes that portfolio standardisation often requires at the individual business level.
- Post-acquisition technology playbook: the first 100 days covers how to approach technology in the immediate post-acquisition period, before standardisation becomes the primary focus.
- Technology due diligence: what investors actually need to know examines how to assess technology risk and readiness at the point of acquisition, which directly informs the standardisation strategy.
Next steps
If you are developing a technology strategy across a PE portfolio, get in touch to discuss how an advisory engagement might support the work.
What to read next
- Technology due diligence: what investors actually need to know: The assessment framework that informs which portfolio companies need standardisation investment and where to prioritise.
- Post-acquisition technology playbook: the first 100 days: The operating rhythm that creates the foundation for effective portfolio-level standardisation.
- The retail operating model nobody talks about: The product-led technology model that makes standardisation sustainable across a portfolio.