In a franchised network the integration boundary is not the company boundary: franchisees are independent businesses running their own point-of-sale, back office and sometimes their own suppliers, so the corporate ESB cannot mandate a change — it can only publish an interface and make adoption worth it. Three consequences follow. The estate scales on store count rather than message volume, which produces the same long tail that makes per-endpoint pricing painful. Onboarding a site is the highest-frequency operation and should be a repeatable product rather than a project each time. And because stores lose connectivity routinely, store-and-forward with reconciliation is a requirement, not a resilience nicety — the failure that hurts is not an outage, it is a store that came back online and silently never caught up.
Enterprise integration mostly assumes a comfortable thing: that both ends of every flow ultimately answer to the same CIO. Change the interface, run a project, upgrade both sides, done.
In a franchised network — restaurants, convenience, automotive dealers, fitness, hospitality, anything with an owner-operator model — that assumption is false in a way that reshapes everything downstream. Half the systems in your estate belong to businesses you do not control, run by owners with their own margins, their own IT budgets, and no obligation to care about your integration roadmap.
The estate is not harder because the technology is harder. It is harder because the integration boundary and the org-chart boundary are different lines, and almost no integration guidance is written for that.
01 / The structural fact
You cannot mandate. You can only publish.
Inside a wholly owned estate, an interface change is a scheduling problem. Across a franchise boundary it is a negotiation with several hundred counterparties who each individually decide whether to bother.
Versions are permanent, not transitional
You will run two or three versions of the same interface simultaneously and for years, because the tail of sites will not upgrade on your timetable. Design for concurrent versions from the start rather than treating the old one as a migration state that ends.
The interface is a product with users
It has documentation, a support contact, a changelog and a deprecation policy — or it has none of those and a franchisee’s IT provider guesses. The quality of that documentation is a real determinant of adoption rate, which is not a sentence anyone expects to write about an internal integration.
Adoption has to be worth something to them
A franchisee adopts an integration because it saves their staff time, reduces their stockouts or gets them paid faster — not because corporate would like better data. Flows designed only for corporate reporting get quietly deprioritised at the store.
You inherit their vendors
The point-of-sale vendor, the back-office package, the local IT provider. Your integration estate has a supplier list you did not choose and cannot consolidate, and each of those vendors has their own release cycle that you find out about afterwards.
In a wholly owned estate you deploy an interface. In a franchised one you launch it, and then you watch the adoption curve like a product manager.
The mental shift that makes the rest of it make sense
02 / The shape
Four traffic patterns, each with a different failure mode
| Pattern | What it must guarantee | How it actually fails |
|---|---|---|
| 1 · Push, one to many menu, pricing, promotions |
That every site is on the same version by the time the promotion starts. Effectively-atomic across the network, on a deadline. | Partial application. Most sites take the update, a handful do not, and one store sells at last week’s price on the day of a national campaign. Nothing errored — one endpoint was unreachable at 3am. |
| 2 · Pull, many to one sales, stock, labour |
Completeness, not speed. Late is fine. Missing is not, because it silently corrupts every report built on it. | A store misses a day and nobody notices, because absence of a file is not an error anywhere in the chain. Discovered at month-end, when reconciliation disagrees. |
| 3 · Real time loyalty, gift cards, authorisation |
Latency and graceful degradation. A person is standing at a till. | Loudly, immediately, with a queue of customers. This is the only one that gets fixed quickly, which is why it is also the best understood. |
| 4 · Supplier EDI 850, 856, 810 |
Correctness and acknowledgement discipline, exactly as in any other EDI estate. | Ordinary EDI failure modes, with the extra wrinkle that the ordering party may be the franchisee rather than corporate — so the trading relationship is not yours to fix. |
Patterns 1 and 2 are where multi-site estates carry their real risk, and both fail silently. That is the same structural problem as any case-based estate: platforms detect failure, and these two fail by absence.
03 / Scale
Store count is the dimension, not throughput
A four-hundred-site network generates modest message volume per site and an enormous number of endpoints. That is the same long-tail shape a twenty-year-old BizTalk estate has, arrived at from a completely different direction — and it has the same commercial consequence.
What scales with store count
The real cost drivers
- Endpoints, credentials and certificates to manage and rotate
- Onboarding events — every new or refitted or sold site
- Version drift across the estate
- Support surface: someone must answer when one site’s feed stops
- Per-endpoint licence cost, if your platform charges that way
What does not
Where the usual sizing conversation goes
- Peak throughput — usually modest and predictable
- Message size
- Transformation complexity, once the first store is done
- Compute, which is why capacity planning is the easy part here
If your platform prices per connection or per endpoint, a franchise estate is close to the worst possible shape for that meter — hundreds of low-volume endpoints each carrying the same licence weight as a high-volume one. Worth modelling before signing anything, and it is the same arithmetic as the per-connection pricing question on the product side.
04 / The failure that matters
The store that came back and never caught up
Store connectivity is not enterprise connectivity. A site loses its line because of weather, a builder, a router someone unplugged to charge a phone. It comes back an hour later, or the next morning.
What happens in that hour decides whether you have an integration estate or a reconciliation problem:
The site buffers locally and drains on reconnection
Transactions queue at the store, replay in order when the link returns, and the corporate side is idempotent enough to absorb anything that arrives twice. Nobody hears about it. This is store-and-forward, and in a multi-site estate it is a requirement rather than a resilience nicety.
The push was missed and never retried
The pricing update went out while the store was dark. There was no retry, or the retry window closed. The store is now on a stale price list and will stay there until someone notices — which may be a customer at the till.
The pull is missing a day and nothing said so
Sales for that day were never sent. No system expected them, so no system complained. It surfaces at month-end as a reconciliation variance, and by then the reason is four weeks cold.
The catch-up replays without idempotency
The store reconnects and re-sends its whole buffer, including the portion that had already arrived. Now sales are double-counted, and the fix is a manual data correction with a finance audience.
Not sophisticated, just frequently missing
05 / The highest-frequency operation
Onboarding a site should be a product, not a project
In a growing network, connecting a new site is the thing the integration team does most often — new openings, refits, changes of ownership, acquisitions of small operators. If each one is a small project with a person attached, integration becomes the constraint on expansion, and everybody notices.
A template, not a build
One parameterised configuration per point-of-sale vendor, instantiated with site-specific values. New site of a known type should be configuration, reviewed and deployed the same day.
Self-verifying
An automated end-to-end check the day a site connects: send a test transaction, confirm it lands, confirm the push reaches it, confirm the version reported is current. Signed off by the check, not by an engineer’s recollection.
Reversible
Sites close, change owner and leave the network. Offboarding cleanly — credentials revoked, expectations removed so absence stops alerting — is the step that never gets built and quietly poisons your monitoring with permanent false alarms.
Documented for their IT provider
The person doing the work at the other end usually does not work for you. What they need is a short specification, a test endpoint and a named contact — and providing those well is the cheapest adoption-rate improvement available.
06 / Modernising
Sequence by site cohort, not by interface
When this kind of estate moves platform, the instinct is to migrate interface by interface across all sites at once. In a franchise network that is the riskiest available order, because a partly migrated interface across four hundred independently operated sites is very hard to reason about and harder to roll back.
| Step | What it looks like | Why this order |
|---|---|---|
| 1 · Cohort by vendor | Group sites by point-of-sale and back-office vendor rather than by geography or size. | The integration work is per vendor, not per site. One cohort done is a template that covers everything else on that vendor. |
| 2 · Start with corporate-owned sites | Migrate the sites you actually control first, all four traffic patterns end to end. | You can schedule them, you can break them, and you can fix them without a phone call to an owner. Learn there. |
| 3 · Then the most engaged franchisees | The operators who answer email and have real IT support. Usually the larger multi-unit ones. | They will tell you what is wrong with your documentation, which is what the rest of the rollout depends on. |
| 4 · Parallel run across a full trading cycle | Both platforms receiving, outputs compared, through at least one month-end. | Reconciliation and settlement are monthly. A parallel run that ends before month-end has not tested what finance cares about. |
| 5 · The long tail, with a deadline and support | Publish the date, publish the spec, staff a help line for the fortnight around it. | The tail does not move without a date, and it does not move happily without support. Both, or you will run two platforms for years. |
07 / Next
Two numbers to establish first
Before any platform conversation, get these: how many sites reported the current version of every pushed artifact yesterday, and how many sites are missing at least one expected inbound file in the last thirty days. Most networks cannot answer either without manual work, and both answers usually surprise people.
If the second number is not zero, you have a reconciliation exposure that exists today, independent of any migration — and finding it is worth the afternoon regardless of what you do next.
We have run integration for distributed, multi-site estates in production for twenty years — retail, distribution and manufacturing — and we are Microsoft V-TSP recognized for BizTalk Server. If the network is growing faster than integration can onboard it, that is the conversation to have.
Call (678) 203-0800.
Frequently asked questions
What makes franchise integration different from normal enterprise integration?
The integration boundary is not the company boundary. Franchisees are independent businesses running their own point-of-sale, back office and sometimes their own suppliers, so corporate cannot mandate an interface change — it can only publish an interface and make adoption worth the franchisee’s while. That single fact means multiple interface versions run concurrently for years, the interface needs documentation and a support contact like a product, and flows designed purely for corporate reporting get deprioritised at the store.
What scales in a multi-site integration estate?
Store count, not throughput. A four-hundred-site network usually has modest and predictable message volume per site and an enormous number of endpoints, so the real cost drivers are credentials to rotate, onboarding events, version drift, support surface and per-endpoint licensing. Compute and peak throughput — the things a normal sizing conversation focuses on — are the easy part.
What is the most common silent failure in a multi-site estate?
A site that lost connectivity, came back, and never caught up. Either a pushed update was missed while the site was dark and never retried, leaving that store on a stale price list, or a scheduled inbound file was never sent and no system expected it, so nothing raised an error and the gap surfaces at month-end as a reconciliation variance. Both fail by absence rather than by error, which is what makes them hard to catch.
How do you stop a store double-counting when it reconnects?
Idempotency on every inbound, keyed on a business identifier per transaction, so a store that replays its whole local buffer on reconnection has the already-received portion absorbed rather than counted twice. Without it, the recovery mechanism that protects you from an outage becomes the thing that creates a manual data correction with a finance audience.
What is the difference between confirmed delivery and confirmed application?
Delivery confirmation tells you the message left your side. Application confirmation means each site reports which version of the pricing, menu or promotion it is actually running, so a dashboard shows the laggards before a campaign starts rather than after. Almost no network has the second one, and it is the control that prevents a national promotion launching at 387 of 400 sites.
How should new sites be connected?
As a repeatable product rather than a project. One parameterised configuration per point-of-sale vendor, instantiated with site-specific values; an automated end-to-end verification the day a site connects; a clean offboarding path so closed or sold sites stop generating false alerts; and a short written specification with a test endpoint and a named contact for the franchisee’s own IT provider, who does not work for you. In a growing network, onboarding is the highest-frequency operation the integration team performs.
In what order should a franchise estate be migrated?
By site cohort rather than by interface. Group sites by point-of-sale vendor, because the work is per vendor rather than per site. Migrate corporate-owned sites first, since you can schedule and break those without a phone call. Then the most engaged franchisees, who will tell you what is wrong with your documentation. Run parallel through at least one month-end so reconciliation and settlement are actually tested, and move the long tail with both a published deadline and staffed support — a deadline without support leaves you running two platforms for years.
Jorge Pastorini · Cerebrum City
Cerebrum City is a Microsoft V‑TSP–recognized BizTalk specialist in Atlanta, Georgia, with two decades running BizTalk Server in enterprise production for clients including Humana, Deloitte, JetBlue, and U‑Haul.
Want this mapped against your BizTalk estate?
We inventory your ports, orchestrations, maps, and adapters, flag the interfaces most likely to break, and hand back a staged Azure roadmap. No obligation.
