August 22, 2026
A multi-location connectivity assessment that starts with one circuit usually fails at the second site, not at the first quote. Headquarters-to-cloud is one path. Clinics, stores, or plants are another. If you do not write the inventory first, you buy a circuit and inherit 600 exceptions.
That is why the live multi-location connectivity assessment starts with location inventory, a dependency map, and decision timing. This post does not replace that page. It is a supporting note on why a single-circuit ask is not the design.
What the public case is actually about
A Telarus "Inside the Win" write-up describes a medical manufacturer that asked for one connection between two locations into Azure. Traditional carrier lead times were months. The published story then expands to hundreds of doctor offices already paying for site-to-cloud VPNs. The dollar figures, lead-time claims, and Graphiant branding are theirs, not ours.
Use it as a requirements example only: write every site, every cloud path, and whether a "fast circuit" would still leave the other locations on a different operating model. It is not a Data Partner engagement, not a TDP win, and not a recommendation of Graphiant or any NaaS brand.
What to add to the assessment
Before a quote, fill these rows:
- Location inventory: current and planned sites, what each site actually does, renewal or move dates.
- Dependency map: cloud, SaaS, voice, security, and customer-facing workflows that die if a path dies.
- Site-to-cloud vs site-to-site: which offices only need the internet, and which must reach a tenant or a partner.
- Timing: decision date, construction, and what cannot wait 90 days.
- Owner: who accepts a different design per site versus one fabric for all of them.
The redundancy and failover worksheet is the companion for a single site. It is not a substitute for the multi-location brief.
Questions that belong in the first meeting
Ask the provider to show, not describe:
- How a new site is added without a 90-day special project.
- What a clinic or store path looks like versus headquarters.
- Who owns the VPN or fabric when a SaaS or Azure path fails.
- What evidence you get after a location cannot pass traffic.
- Which sites stay on a different underlay, and why that is acceptable.
If they cannot show those, they are selling one circuit, not a multi-location design.
What not to do
Do not treat a podcast as a TDP case study. Do not paste MRR, lead-time guarantees, or NaaS brand claims onto this site. Do not collect service addresses in the first public form. Do not publish this as a TDP win.
Write the inventory. Then compare.
Sources
- The Data Partner, multi-location connectivity assessment (live): https://thedatapartner.com/multi-location-connectivity-assessment/
- The Data Partner, business internet redundancy and failover requirements: https://thedatapartner.com/business-internet-redundancy-failover-requirements/
- Telarus, "Inside the Win: How Graphiant Turned 1 Circuit into 600 Connections," outbound watch only: https://www.telarus.com/resources/inside-the-win-how-graphiant-turned-1-circuit-into-600-connections/