Integrating acquired brands without slowing the field

Private equity has turned home services into a platform business. A holding company acquires regional brands in windows, roofing, bath or HVAC, keeps the local names customers trust, and tries to run them on shared operations. The financial logic is clear. The technology work underneath it is where many integration plans lose months.

Each acquired brand arrives with its own scheduling tool, its own CRM habits, a spreadsheet that someone in dispatch cannot live without, and a few integrations that nobody has documented. The field keeps selling and installing every day, so the platform cannot pause operations while IT catches up. This article describes how we approach that problem after 20+ years of building and operating software for companies in this situation, including a partnership of more than eight years with a multi-brand home improvement platform in the U.S.

The real constraint is not the code

Most integration roadmaps are written as if the main task were picking a target system and migrating everyone onto it. In practice, the constraint is operational continuity. Sales reps need appointments assigned every morning. Installers need job details on their phones. Call centers need to see availability across brands in real time. If any of those flows breaks for a week, revenue drops and trust in the integration program drops with it.

That changes the order of the work. Instead of starting with the target platform, start with the flows the field depends on and ask three questions for each one:

1. Who uses it every day, and what happens if it is down for an hour?
2. Which data does it need, and where does that data live today in each brand?
3. Can it run on a shared service while the brands keep their current front ends?

The answers usually show that a handful of flows (lead intake, appointment setting, route assignment, job handoff to installation) carry most of the operational risk. Those are the flows to stabilize first.

Consolidate services before you consolidate screens

A common mistake is to force every brand onto the same user interface early. Reps and installers resist it, adoption lags, and the team spends its energy on training instead of engineering.

A more durable approach is to consolidate the services behind the screens first:

• One lead and appointment service that every brand writes to, even if each brand keeps its own intake forms for a while.
• One scheduling and routing engine with business rules that can vary by brand, territory and product line.
• One event stream (job created, appointment confirmed, install completed) that downstream systems subscribe to, instead of point-to-point integrations between each brand’s tools.

Once the services are shared, replacing individual front ends becomes a series of small, reversible changes rather than a single high-risk cutover.

Route assignment: where integration pays off first

Route and appointment assignment is often the first place a platform sees measurable value from consolidation. In one engagement, a legacy route assignment system had become rigid and difficult to extend, and it was limiting how efficiently the sales team could operate. We started with a system audit and interviews with the people who used the tool every day, then prototyped new flows based on how reps actually worked.

The resulting platform combined custom assignment logic (dynamic business rules, traffic and visit timing) with embedded maps for route visibility, built on a low-code orchestration layer that kept infrastructure costs down and made future changes faster. The outcome the business cared about was operational: less travel time, more daily visits, and reps who trusted the tool. You can read the full story in our case studies.

The lesson for platforms is that assignment logic is shared across brands even when products differ. Building it once, with rules configurable per brand, is one of the highest-leverage moves in the integration plan.

Keep brand differences in configuration, not in code

Acquired brands differ in legitimate ways: pricing models, appointment lengths, financing partners, service areas. The temptation is to fork the code for each one. That works for the first two brands and becomes unmanageable by the fifth.

Treat brand differences as data:

• Business rules per brand and territory stored in configuration, with an audit trail.
• Feature flags to roll capabilities out brand by brand.
• A shared domain model (lead, appointment, job, crew, territory) with brand-specific attributes as extensions, not separate schemas.

This keeps the core platform maintainable and makes the next acquisition faster to onboard, which is the point of building a platform in the first place.

Data first, then dashboards

Leadership teams at PE-backed platforms want consolidated reporting early, and they should get it. But a dashboard built on inconsistent definitions creates arguments instead of decisions. What counts as a qualified lead in one brand may not in another. Close rates calculated differently will not roll up.

Before building cross-brand reporting, agree on a small set of shared definitions and enforce them at the service layer. The dashboards then become a byproduct of clean operational data rather than a separate project that needs constant reconciliation.

How to staff the integration

Integration programs fail quietly when the team is either too thin to keep up with the field or too expensive to sustain for the 12 to 24 months a multi-brand consolidation usually takes. A model that works well in our experience:

• Mid-level and junior engineers embedded in the platform’s team, working in U.S. time zones, carrying the steady flow of integration work: new connectors, migrations, configuration, fixes.
• Senior engineers and tech leads who step in as complexity grows, from unblocking the team on a difficult data migration to taking on on-demand hours for architecture decisions such as the event model or the routing engine.
• Continuity across acquisitions, so the people who integrated brand three already know the domain when brand four arrives.

This structure keeps production stable while controlling cost, which matters when the integration budget is part of the investment thesis.

A practical sequence

For platforms starting or restarting an integration program, this sequence reduces risk:

1. Map the critical flows across brands and rank them by operational impact.
2. Stand up the shared services for leads, appointments and routing, with brand rules in configuration.
3. Connect existing front ends to those services so brands keep working while the core changes.
4. Replace front ends gradually, brand by brand, behind feature flags.
5. Build consolidated reporting on shared definitions once the data is flowing through common services.
6. Document the onboarding path so the next acquisition follows a known playbook.

The bottom line

The goal of a multi-brand platform is to make each new brand easier to integrate than the last. That happens when the shared services are stable, brand differences live in configuration, and the team doing the work stays with you long enough to learn the domain.

If your platform is integrating acquired brands and the field cannot afford a slowdown, talk to us. We will start with the flows your crews depend on every day.