Firing Your MSP Without Breaking Anything: How a Hong Kong Trading Company Switched Providers

Switching IT providers doesn't have to mean an outage. A structured transition — site survey, knowledge transfer, a documented CMDB, and a shadow period running old and new support in parallel — replaces the leap-of-faith cutover most companies fear, and gives a Hong Kong trading company a defined, low-risk path off an incumbent MSP it no longer trusts.

The Industry: Always-On Is Not Optional for Cross-Border Trading

A Hong Kong trading or sourcing company doesn't run on a nine-to-five clock. Email threads with suppliers in Shenzhen, Ho Chi Minh City, and Jakarta move through the evening. The ERP system that tracks purchase orders, container bookings, and supplier payments has to be reachable from a warehouse floor, a supplier's factory, and a sales rep's laptop at an airport lounge, often across three time zones in the same afternoon. A trading company's entire value proposition — being the reliable middle layer between an overseas buyer and an overseas factory — depends on communication and data systems that simply do not go down.

That dependency is exactly why IT problems in this industry don't stay small. A mail server outage during a supplier negotiation isn't an inconvenience, it's a missed shipment window. A VPN that drops when a purchasing manager is trying to confirm a container booking from a factory floor in Dongguan is a lost afternoon, and sometimes a lost order. For a company this exposed to IT reliability, the provider managing that infrastructure isn't a vendor relationship in the abstract — it's the thing standing between "business as usual" and a very bad week.

Which is what makes an underperforming incumbent MSP such an uncomfortable problem. The company knows the current provider isn't good enough. It has known for a while. And it still hasn't switched — not because the incumbent is acceptable, but because nobody can describe, with any confidence, what the actual switch would look like.

The Scenario: Three Aborted Departures in One Year

This is a composite, illustrative scenario built from patterns Brocent sees across Hong Kong trading and sourcing companies — not a single named client. The operations director at a ~60-100 staff Hong Kong trading company has, by her own count, decided to leave the company's IT provider three separate times in the past year. Each time, she got as far as researching alternatives before backing off.

The reasons she backed off were consistent. The company has been with its current provider for years. Nobody wrote anything down along the way — there's no current network diagram, no asset register anyone trusts, no documented list of which vendor owns which piece of the stack. The knowledge of how the environment actually works lives almost entirely in the heads of two engineers at the incumbent provider, one of whom answers the phone reliably and one of whom doesn't. When something breaks, it gets fixed. Nobody has ever had to explain the environment to someone new, so nobody ever built the explanation.

Against that backdrop, "switching providers" doesn't sound like an upgrade. It sounds like handing the keys to an unfamiliar team and hoping they can reverse-engineer, cold, an environment the current provider barely explains even to its own client. The operations director's fear isn't really about the new provider's competence — it's that nobody has ever shown her what a good transition looks like, so she has no way to distinguish a well-run switch from a chaotic one until it's already happening to her.

What Undocumented Tribal Knowledge Actually Costs You

The real cost of this situation isn't the mediocre support tickets the company is currently tolerating — it's the compounding risk of staying somewhere it doesn't trust because leaving feels riskier than the status quo. That trade-off gets worse every quarter it continues, for three specific reasons.

First, the tribal-knowledge problem doesn't stay fixed at its current size — it grows. Every new server, every new SaaS subscription, every ad-hoc firewall rule added without documentation makes the eventual transition (to anyone — not just to Brocent) more expensive and more risky, because there's more undocumented surface area to reconstruct later.

Second, staying with an incumbent purely out of transition anxiety, rather than because the service is genuinely acceptable, means the company keeps absorbing whatever service level the incumbent happens to deliver. There's no negotiating leverage in a relationship the other side knows you're afraid to leave.

Third, and most concretely: an undocumented environment is itself a business continuity risk independent of who manages it. If the two engineers who understand the environment both leave the incumbent provider, or the incumbent provider itself has a bad quarter, the trading company inherits an emergency it had no hand in creating — with no runbook, no CMDB, and no fallback plan.

None of this means the operations director was wrong to hesitate. An undocumented, unplanned cutover really would be risky. The problem isn't her instinct — it's that "risky, undocumented cutover" and "professionally managed transition" have been treated as the same thing, when they're not.

There's also a cost-predictability angle that gets lost in the anxiety around switching. An incumbent provider that isn't managing proactively tends to bill reactively — a break-fix call here, an emergency after-hours rate there, an unplanned project fee when something finally fails hard enough to force attention. None of that shows up as a single, comparable monthly number, which makes it genuinely difficult for an operations director to build a defensible IT budget for the year ahead, let alone argue for a change when the current spend is scattered across a dozen line items instead of one. A trading company's finance team can approve a fixed per-user monthly figure far more easily than it can approve "we're not sure, it depends what breaks" — and that predictability gap is itself a reason the switch keeps getting deferred: nobody wants to trade a bad-but-familiar unpredictable cost for an unknown one.

Why This Risk Lands Harder on Trading and Sourcing Companies Specifically

Not every business feels an IT transition the same way, and it's worth being specific about why a trading or sourcing company sits closer to the sharp end of this than, say, a professional-services firm with a single office and a nine-to-five client base.

A trading company's operations are, by definition, distributed across time zones and counterparties it doesn't control. Supplier factories in Guangdong or Vietnam run their own schedules; buyers in Europe or North America run theirs; the trading company's own staff are often split between a Hong Kong head office, a mainland sourcing office, and travelling sales and QC staff. Email and the ERP system are the connective tissue holding that structure together — there is no equivalent of "wait until the branch reopens tomorrow" when a supplier needs a purchase order confirmed before their production line starts. An IT gap doesn't just inconvenience internal staff; it stalls a live commercial transaction with a counterparty who has no visibility into, and no patience for, the trading company's internal IT problems.

That's also why the tribal-knowledge problem compounds faster in this industry than in a more contained business. Every new supplier onboarded, every new region added to the sourcing footprint, and every new compliance requirement from an overseas buyer tends to generate its own ad-hoc IT accommodation — a VPN exception here, a shared drive permission there, a one-off integration with a customs broker's system — none of which gets written down if the incumbent provider isn't running a disciplined change-management process. By the time an operations director is seriously considering a switch, the undocumented surface area isn't just "the network" in the abstract; it's years of accumulated, invisible accommodations for exactly the cross-border complexity that makes the business run.

A Transition Is a Project With a Defined Shape, Not a Leap of Faith

This is the core of Brocent's perspective, and it's grounded in how Brocent actually runs IT transition and onboarding for incoming managed IT clients: switching providers is a structured, multi-phase project with a known shape — not a single high-stakes cutover date where everything either works or it doesn't.

Phase 1 — Site Survey & IT Audit (Weeks 1–2)

The transition team visits the trading company's offices and warehouse sites to run a structured IT audit: asset inventory, network topology mapping, a review of data classification and backup policy, and identification of the top infrastructure weaknesses inherited from the outgoing setup. This phase exists precisely because the incumbent never documented anything — the audit rebuilds the picture of the environment from the ground up rather than relying on what the old provider is willing (or able) to hand over.

Phase 2 — Knowledge Transfer & CMDB Build (Weeks 2–4)

Where the outgoing provider is willing to cooperate, this phase includes formal knowledge-transfer sessions with them. Where it isn't — and MSP transitions where the incumbent is uncooperative are common enough that the process is built to handle it — the audit findings from Phase 1 carry the load instead. Either way, the deliverable is the same: a Configuration Management Database (CMDB) covering every asset, configuration, and software licence, built on Brocent's IT management platform, plus written Standard Operating Procedures for recurring tasks. This is the step that converts "two people at the old provider know how this works" into a document anyone on the new support team can read.

Phase 3 — Shadow & Re-Shadowing (Weeks 3–6)

This is the phase that most directly answers the fear behind three aborted departures. Brocent engineers run support processes side by side with the existing setup, or under observation, until they meet a defined competency benchmark — before they take over anything unsupervised. During this window, both the old and new support arrangements are effectively live at once. Nothing depends on a single cutover date working perfectly, because nothing has fully cut over yet.

Phase 4 — Go-Live & 30-Day Post-Transition Review (Month 3 onward)

Full responsibility transfers to the new managed IT service only after the shadow period demonstrates readiness. From go-live, the trading company gets a defined SLA (a 15-minute first response for priority-one issues), 24/7 monitoring, and a single point of contact with a clear escalation path. Thirty days after go-live, a formal review checks for any knowledge gaps that surfaced during the first month of real operation, and the runbook gets updated to close them — so the documentation keeps improving even after the transition is technically finished.

For smaller or better-documented environments, this whole sequence can compress to four to six weeks rather than the full three months; for multi-site or multi-country trading operations, Brocent runs parallel surveys and knowledge-transfer sessions across sites to keep the timeline consistent.

Two details of this structure matter enough to spell out separately, because they're exactly the details that determine whether "switching providers" feels safe or reckless in practice. First, admin access is requested only temporarily, and only for the phases that need it — the knowledge-transfer and CMDB-build window — rather than being handed over wholesale on day one before any trust has been established. Second, where existing documentation exists at all, even partial or outdated documentation from the incumbent, the audit phase incorporates it rather than starting from zero; the audit only has to rebuild from scratch the parts nobody wrote down, which is usually most of it, but not always all of it.

What This Looks Like in Practice

For a Hong Kong trading company specifically, three things about this structure matter more than the general description above.

The first is that nothing depends on a single date. The shadow phase means the incumbent provider's support (however mediocre) and the incoming team's readiness overlap — the trading company isn't choosing between "keep tolerating the current provider" and "bet the business on a cold cutover." There's a middle path where both are running, and the switch happens only once the new team has demonstrably earned the handoff.

The second is that the transition produces exactly the artifact the current situation is missing: a CMDB and a technical runbook that document the environment for the first time, covering infrastructure architecture, vendor contacts, an escalation matrix, licence renewal dates, backup procedures, and known historical issues. That runbook doesn't just serve day one of the new relationship — it's the reason the *next* transition, whenever it happens, won't recreate this same three-aborted-attempts problem.

The third is what happens after go-live isn't a cliff-edge either. The 30-day review is a formal checkpoint specifically built to catch the knowledge gaps that only show up once real operational load hits the new arrangement — the parts of an environment that never came up during the audit because nobody thought to mention them until something happened that needed them.

There's a fourth point worth making explicitly, because it's the one that ties the transition back to why the company was looking to switch in the first place: go-live isn't the finish line, it's the start of ongoing management under a defined service model. Once the transition completes, the trading company isn't back in the same position it was in with the incumbent — informally supported, undocumented, and dependent on two people's memory. It's on a managed IT plan with 24/7 monitoring, a named escalation path, and monthly reporting, which is the structural difference between a provider relationship that erodes quietly over years (as the incumbent's did) and one that stays accountable because the account itself is actively managed, not just reactively supported.

Frequently Asked Questions

Will switching providers cause downtime?

Not if the transition is run as a structured, phased project rather than a single cutover. The shadow-and-re-shadowing phase specifically exists to run the new support team's readiness in parallel with the existing arrangement before anything switches over, so end users aren't the ones discovering gaps in real time.

How long does a typical transition take?

A full structured transition is typically framed around a three-month timeline — survey and audit in weeks one to two, knowledge transfer and CMDB build in weeks two to four, shadow and re-shadowing in weeks three to six, and go-live from month three onward. Smaller or better-documented environments can complete in four to six weeks; larger, multi-site, or multi-country operations may take longer, with parallel workstreams keeping the schedule consistent across sites.

What if the outgoing provider won't cooperate?

It happens, and the transition process is designed around that possibility rather than assuming it away. When an incumbent won't participate in formal knowledge-transfer sessions, the site survey and IT audit in Phase 1 do more of the work — rebuilding the environment picture directly from what's observable on-site and in the systems themselves, rather than depending on the old provider's goodwill.

Do we need to migrate everything on one cutover date?

No. The whole point of the phased structure is to avoid a single all-or-nothing date. Go-live happens only once the shadow phase has demonstrated the new team can operate the environment independently — the transition is staged, not switched on all at once.

What happens if something breaks during the transition?

During the shadow phase, the existing support arrangement is still live, so day-to-day issues are still being handled through the channel the company already knows. Full operational responsibility, including SLA-backed incident response, only transfers at go-live — after readiness has been demonstrated, not before.

How is a new provider onboarded to systems nobody documented?

Through the site survey and audit phase, which exists specifically for this situation. Rather than relying on inherited documentation that doesn't exist, the incoming team builds an asset inventory, network topology map, and CMDB from direct observation of the live environment — the documentation gets created as part of the transition itself, not assumed to already exist.

What should be in a transition contract?

At minimum: a defined scope for the audit and knowledge-transfer phases, a clear shadow-period timeline with named readiness criteria before go-live, the SLA terms that take effect at go-live (including first-response time for priority incidents), and confirmation that a technical runbook and CMDB are contractual deliverables of the transition, not optional extras. It's also worth confirming upfront whether transition costs are folded into the ongoing managed IT services contract or billed as a separate statement of work — for a complex multi-site trading operation, a dedicated transition SOW is often the cleaner arrangement, since it scopes the one-time takeover work separately from the recurring per-user plan that follows it.

Does our current provider need to know we're planning to leave?

Eventually, yes — the knowledge-transfer phase works best with the outgoing provider's cooperation. But the site survey and audit in Phase 1 don't depend on that cooperation being available on day one, which means a company can start the process, and get a realistic picture of what a transition would actually involve, before having that conversation with the incumbent.

Three Ways Companies Handle This Decision

Staying put out of fear — the incumbent provider isn't good enough, but the switch itself feels riskier than the problem it would solve. The company keeps absorbing whatever service level the current provider delivers, with no negotiating leverage and a tribal-knowledge gap that only grows the longer it continues.

An undocumented rip-and-replace cutover — fast on paper, and genuinely high-risk in practice. Everything moves on a single date with no shadow period, no formal knowledge transfer, and no chance to catch gaps before they hit end users. This is the scenario the operations director was right to fear — it's just not the only alternative to staying put.

A structured multi-month takeover with shadow support — the Brocent model: a defined site survey and audit, formal knowledge transfer where the outgoing provider cooperates (and a rebuild-from-observation fallback where it doesn't), a documented CMDB and runbook, a shadow period running old and new support in parallel, and a go-live gated on demonstrated readiness, followed by a 30-day review that keeps closing gaps after the switch is technically complete.

The Question Isn't Whether to Switch — It's Whether the Switch Has a Shape

The operations director in this scenario didn't need convincing that her current provider wasn't good enough — she'd known that for a year. What she needed was a way to tell a well-run transition apart from the chaotic one she was picturing, and evidence that the difference is a project plan, not luck.

That's what the transition process above is: the specific mechanism by which a Hong Kong trading company moves off an incumbent MSP and onto Brocent's managed IT plan without betting the business on a single cutover date. The takeover itself — site survey, knowledge transfer, CMDB build, shadow support, go-live, and 30-day review — is how a company gets from "afraid to leave" to a per-user managed IT plan with a defined SLA, 24/7 monitoring, and a single point of contact, without the gap in between being the thing that goes wrong. Current pricing for the plan tiers a trading company of this size would land in is published and per-user, not a custom quote you have to negotiate blind before you've even agreed to talk.

If three aborted departures sound familiar, the honest next step isn't researching providers from scratch again — it's talking through what a structured transition would actually look like for your specific environment, so the switch stops being the thing standing in the way of leaving a provider you've already decided to leave.