Platform strategy for mergers, acquisitions & divestment

Building a unified platform is hard enough in a stable organization. In a corporate group that is constantly acquiring, merging, and divesting business units, it becomes one of the most complex challenges in modern engineering. Unlike traditional platform scenarios where a dominant core absorbs smaller entities, group environments offer no obvious technical standard, no stable organizational baseline, and the ever-present possibility that what you integrate today must be separated tomorrow.

Main insights

• Groups built from multiple similar-sized acquisitions face fundamentally different platform challenges than traditional M&A scenarios where a large company absorbs smaller ones.

• Platform architecture decisions must align with business valuation drivers - growth-focused companies need integration speed over efficiency, while EBITDA-focused companies can optimize for consolidation.

• Divestment readiness requires intentional architectural choices: building platform services as licensable products, accepting strategic redundancy, and maintaining separation boundaries even while consolidating.

• A connected data graph linking technical metrics to business outcomes is the foundation for every meaningful platform decision in a group setting.

Željko Obrenović brings a rare perspective to this challenge. As Chief Group Architect and Director of Platform Engineering at Aviv Group - a collection of real estate classifieds brands across multiple markets - he manages both the strategic architecture vision and the day-to-day platform engineering execution. His experience spans similar group environments at eBay Classifieds and Adevinta, giving him deep insight into the patterns and anti-patterns of platform engineering in constantly transforming organizations.

You can watch the full discussion here if you missed it: Platform strategy for mergers, acquisitions & divestment

What makes group platform engineering different

The fundamental challenge in group settings stems from how these organizations form. In a traditional M&A scenario, a large acquirer absorbs a smaller company, which gradually adopts the acquirer's platform, processes, and culture. Groups work differently.
"You end up with three, four or five companies of similar size and complexity," Jansma explains. "There's no one dominant player that will define how things are going to work." These organizations grow through multiple independent acquisitions - often 50/50 or 60/40 splits rather than 90/10 - leaving you with an "incredibly diverse landscape without obvious consolidation points."

The situation becomes even more complex because groups rarely stay static. Acquisitions and divestments can occur within the same two-year window. You might acquire a company, make meaningful transformation progress, onboard teams to a shared platform - and then face a divestment decision. Suddenly a brand that has become deeply dependent on your shared infrastructure needs to become independent again, typically within 12 to 24 months.

Choosing your platform path when there is no obvious answer

When you have multiple similar-sized platforms and no dominant standard, how do you choose a path forward? Jansma has worked through nearly every approach:

• Big bang rebuild: Start fresh with lessons learned from all existing platforms. "It's almost never an option because you don't have the time," he notes.

• Pick the best: Select the strongest existing platform, make it more generic, and migrate others to it. This works when one platform is clearly superior - but that is rarely the case.

• Gradual convergence: Slice capabilities into smaller pieces and modernize slice by slice rather than attempting wholesale platform alignment.

"I cannot say that one of these approaches is better or worse," Jansma admits. "I've tried kind of everything. There is definitely learning, you deliver some value, but it's always shorter than you expect."

What does help is rigorous, data-driven modeling that connects your technical landscape to business and product context. "You cannot just look at the infrastructure, source code - you need to really get finance, product, business involved," he emphasizes.

One critical anti-pattern to avoid: attempting to modernize the technical platform while keeping local business operations unchanged. Consolidation requires trade-offs. "You get much more power or generality. You can change things once and get it there. But if you want to keep every minor feature locally, that will create more complexity frequently than before."

Aligning platform strategy with business valuation

A crucial insight that separates successful group platform engineering from failed attempts is understanding how your company is valued - and letting that drive architectural decisions.
"If you value for growth, you need to prioritize ease of integrations, but it will be less efficient," Jansma explains. "It will be messy, it will cost more, but you can quicker get expansions or acquisitions." In this scenario, you accept duplication and independence to maintain velocity.
Conversely, if your company is valued on EBITDA (earnings before interest, taxes, depreciation, and amortization) - a measure of operational profitability - you have more flexibility to increase dependency and consolidation. "You may increase dependency to get bigger valuation, but then you'll pay later on by more effort to decouple," he notes.
This framework helps resolve seemingly impossible trade-offs. When growth is the priority, you optimize for integration speed even at the cost of technical debt. When efficiency drives valuation, you can justify the upfront investment in consolidation while accounting for future decoupling costs.
Critically, this is not a one-time assessment. "Every six, 12 months, you need to be part of discussions and understanding how market is changing, how our investment relationships are changing, and then anticipate a bit what's going to happen," Jansma advises.

Building for divestment from day one

The possibility of divestment creates unique architectural requirements that most platform teams only discover too late. When a brand that has been onboarded to your shared platform needs to be spun out, it faces a painful reality: deep dependencies on central capabilities, relocated or departed staff, and no clear path to independence.
He recommends three strategies to maintain divestment readiness throughout the integration phase:
Build platform services as products. "You could build a platform as if you are building it for an independent software service company, like Amazon built AWS services," he suggests. This allows you to potentially license services to divested brands through contracts rather than forcing complete separation.
Accept strategic redundancy. "Make it a bit more redundant, maybe deploy things twice rather than once so that if there is an option, then you can more easily cut things out." This trades some efficiency for flexibility - a deliberate architectural choice, not an oversight.
Separate infrastructure from code ownership. Deploy shared code in brand-specific infrastructure to enable a two-step separation process. "You first transfer one aspect of the older code and data, they became quickly independent. And then you take longer to transfer the intellectual property and ownership."
The 12 to 24 month divestment window is only workable if you have prepared during integration. Preparation cannot begin when divestment is announced.

Avoiding the over-investment trap

Platform engineering in any context risks over-investment, but group settings amplify this risk significantly. The opportunity space appears enormous - duplication is visible everywhere, and the efficiency gains from consolidation look compelling on paper.
Jansma points to Fred Brooks' second system effect as a particular danger: teams that built one platform for a specific use case finally get the opportunity to build it "right" - more generically, more flexibly. "That could become pretty over-engineered," he warns. "You will end up in this speculative generality anti-pattern where you're building lots of things because maybe there'll be some case there."
His advice: start from business and product vision goals rather than technical opportunities. Analyze your source code and infrastructure, but first ask whether you need that capability at all. "Some of the biggest, maybe the most influential architecture decisions were actually understanding business goals and maybe deciding not to do something completely."
Watch for misalignment between technical and business readiness. If your engineering teams are creating transformation roadmaps while business leaders are still debating the vision for shared platforms, you are likely over-investing. "You need to really be sensitive, understand that there's still lots of back and forth on business product vision before you create roadmap transformation plans on technical ones."

Data as the foundation for platform decisions

Throughout his experience, Jansma returns repeatedly to data-driven decision making. "There is no way you can make any meaningful decision without really relying lots on data."
But not just any data. The key is creating a connected graph that links technical data - source code, cloud billing reports, infrastructure - with business and product data such as revenue, investments, and EBITDA. This connected graph enables you to understand not just what you have technically, but how it maps to business value and cost.
Even when you make mistakes - and you will - the graph helps you recognize them quickly and adjust course. It also gives you a shared language for communicating platform value and trade-offs to non-technical stakeholders, which is essential in group environments where finance, product, and business leaders all have a stake in platform decisions.

Key takeaways

• Align platform strategy with your valuation model before making architectural decisions. Growth-focused companies must prioritize integration speed and accept messiness; EBITDA-focused companies can optimize for efficiency but must account for future decoupling costs. Revisit this alignment every six to twelve months as market conditions shift.

• Build divestment readiness into your platform architecture from day one. Design platform services as potentially licensable products, accept strategic redundancy to enable separation, and maintain clear boundaries between shared infrastructure and brand-specific deployments. The 12 to 24 month divestment window is only sufficient if you have prepared during integration.

• Prevent over-investment by starting with business goals, not technical opportunities. The biggest architectural wins often come from deciding not to build something at all. Ensure business and product vision is clear before creating detailed technical roadmaps, and watch for misalignment between technical enthusiasm and business commitment.

• Create a connected data graph linking technical metrics to business outcomes. You cannot make meaningful platform decisions without data that connects source code, infrastructure, and cloud costs to business metrics like revenue, investments, and EBITDA. This graph enables faster learning from mistakes and clearer communication with non-technical stakeholders about platform value and trade-offs.