In most sectors, integration is about merging processes, systems and teams that do the same kind of work. In the real estate sector, an extra layer is added on top of that: the core activity consists of properties, and each property has its own lease agreements, maintenance status, permits and management arrangements. Two property managers that merge are not combining two comparable business processes — they are combining two collections of unique legal and physical units that cannot be forced into a common template. The balance between what can be standardized generically and what must be looked at property by property lies further toward the latter side here than in most other sectors.
That difference runs through nearly every part of the integration. Taking over a lease agreement is not a matter of adjusting a line in a system; it may contain clauses on change of ownership, tenants' right of first refusal, or a deviating indexation. Merging a maintenance schedule means first finding out which property follows which regime and which regime continues to apply after the deal. Anyone who underestimates this integrates faster than the contracts and permits allow, and that does not produce acceleration but delay at a different point in time.
In real estate too, merging does not automatically add value. Two portfolios with a different geographic focus, a different tenant profile or a different risk profile can perfectly well continue to exist side by side under a single ownership, without management systems, maintenance contracts or local teams needing to merge into one another. For every component — the management system, the maintenance service, the rental administration, the relationship with brokers and contractors — the question is whether merging makes the portfolio stronger or mainly adds complexity to something that functioned well on its own. That question is not an exception to the rule here; it is the rule, and applies equally to sectors with a different structure, as can be read at the bottlenecks a construction company encounters during integration or at the sticking points in the installation industry.
Three spots recur time and again in real estate integrations.
The management system is the first. Property managers often work with software specifically configured for their portfolio — rent collection, maintenance scheduling, service costs, reporting to owners. Merging two of these systems means not only migrating data, but also deciding which way of working becomes the new standard, and what that means for properties that were organized just slightly differently.
Contracts are the second spot. Lease agreements, maintenance contracts, supplier agreements and permits are rarely worded identically, even within a single company. During an integration, someone has to work out which contracts change upon a change of ownership, which continue unchanged, and which need to be renegotiated. That work is labor-intensive and cannot be accelerated simply by linking a system.
Local knowledge is the third. Property management depends in part on knowledge that is not recorded in any system: which tenant is difficult, which contractor is reliable, which property will soon need maintenance that has not yet been scheduled. That knowledge resides with people, and an integration that looks only at systems and contracts misses the risk that this knowledge disappears when teams are merged or downsized.
Synergy in real estate is often calculated in terms of economies of scale in management and maintenance, but those figures are only useful if it is clear who has to realize them after the deal and at what point in time. That applies equally to a single acquisition as to a buy-and-build with multiple platforms; how that substantiation should look is described at building a synergy baseline for buy-and-build, and who within the organization must hold on to the synergy after the deal is addressed at the question of who owns a synergy in buy-and-build.
The three generators from mergerintegration.net — the synergy baseline, the Day 1 plan and the Day 100 plan — are built to make this structure visible rather than obscure it. The synergy baseline forces the question of which part of the portfolio actually benefits from merging and which part is better left separate. The Day 1 plan sets out which contracts, systems and management relationships need immediate attention, so that no tenant or contractor falls through the cracks. The Day 100 plan tracks the dependencies that only become visible later — a system migration waiting on a contract change, a maintenance contract waiting on a system choice. The integration office keeps track of which synergy has been promised, which has actually been realized, and which decision on whether or not to integrate is still open.
None of these components tells you what your specific portfolio should look like; this tooling structures the questions, it does not answer them for you.
Once it is clear which contracts, systems and management tasks belong to the integration, the question follows of who carries out that work — and whether all of it has to be done with the same staffing as before the deal. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, which becomes relevant as soon as management processes, contract review or reporting temporarily or structurally increase in volume during the integration.
The three generators and the integration office of mergerintegration.net are under construction. Anyone who wants to use them as soon as they become available can sign up for the waiting list.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.