What Happens to the Incumbent's On-Site Staff? A Rebadging Story

Short answer: When you switch IT outsourcing vendors, the incumbent's on-site engineers do not have to lose their jobs and you do not have to lose their knowledge. Rebadging moves those same engineers onto the new provider's payroll — same people, same desks, new employer — under a governed transition built around a zero-gap switch date.

There is a moment in almost every IT vendor change where somebody in the room finally asks the question nobody put on the project plan: what happens to the engineers?

Not the contract. Not the ticketing system, the asset register, the licence transfers, or the knowledge-base export. The people. The two engineers who have sat on the third floor for four years, who know that the finance team's shared printer needs its driver rolled back after every firmware update, who know which meeting room's display has never worked properly with the Mac dock, who know the name of everybody they walk past.

By the time that question gets asked, the transition has usually been running for weeks. The procurement decision is made, the new provider is selected, and the plan on the slide deck is a clean, confident sequence of systems and cutover dates. The engineers appear nowhere on it — because in most organisations they are the incumbent vendor's employees, and the incumbent vendor's employees are, on paper, the incumbent vendor's problem.

This article is for the person who asks the question. It is written as a composite scenario rather than a named client, but the mechanics described are the real ones: the phases, the governance and the failure modes are drawn from the transition framework Brocent actually runs.

Who actually runs into this

This is not a small-company problem or a big-company problem. It is a contract-shape problem, and it appears wherever a company has on-site IT staffing supplied by a third party and then decides to change who supplies it.

In practice that means four situations:

• Changing the main contractor. The most common case. The service is working well enough at the desk level and badly enough at the account level — response times drift, escalation is slow, reporting never arrives — so the contract moves. The engineers on site were never the problem.
• Vendor consolidation. Three staffing contracts across four cities, each with its own invoice, its own account manager and its own idea of what an SLA means. Consolidating under one accountable partner means every one of those engineers has to land somewhere.
• A vendor exiting or restructuring. A global provider leaves a market, or changes its delivery model, and the engineers serving your sites need a compliant new employer without a break in service.
• Cost and compliance optimisation. The same people, at a better-governed and fully compliant employment cost, with payroll, statutory benefits and local labour-law obligations properly owned by one party.

What unites them is that the institutional knowledge you are about to lose does not live in a document. It lives in the people you are about to stop paying for.

The scenario: a transition planned around contracts, not people

Take a company with roughly 300 staff across three sites in two countries. IT support is delivered by a mix of remote helpdesk and four full-time on-site engineers, all of them employed by an outsourcing vendor the company has used for six years. The relationship has soured at the commercial level — not at the desk level — and after a proper tender the company selects a new provider.

The transition plan is thorough about everything except one thing. It covers the RMM tooling migration, the credential handover, the asset inventory reconciliation, the licence reassignments, the documentation export and a four-week parallel-run window. It has owners, dates and dependencies.

It says nothing about the four engineers, because nobody involved in writing it had the standing to decide anything about them. Procurement cannot; they are not the employer. The incumbent vendor will not; they are losing the contract. The new provider has quoted for four engineers without knowing who those engineers will be. And the company's own HR function has not been in the room, because on the org chart these four people are a line item in a service contract, not headcount.

Six weeks before cutover, the operations director asks. And the honest answer from every party is a version of *that is not really ours to answer*.

What goes wrong when the people question arrives late

Four things, reliably.

The default assumption becomes that switching vendors means starting over. Because nobody planned otherwise, the working assumption is that the incumbent's engineers leave with the incumbent's contract and the new provider hires four new people. That assumption is rarely examined, and it is expensive. Everything those four engineers know about your environment — the undocumented workarounds, the site-specific quirks, the relationships that make a two-minute desk visit resolve what would otherwise be a forty-minute ticket — walks out on the last day of the contract.

Knowledge transfer becomes a document exercise under time pressure. The standard mitigation is a handover period: the outgoing engineers write things down, the incoming engineers read them. This works for the things that were always writable. It does not work for the rest — and the outgoing engineers are, at that point, people who have just been told their assignment is ending. Their incentive to produce an exhaustive knowledge base in their final fortnight is not what the plan quietly assumes it is.

Severance and notice-period exposure gets handled ad hoc. Who owes what to whom when an on-site engineer's assignment ends varies by country, by contract, and by how the employment relationship was actually structured in practice. In some markets the exposure sits cleanly with the incumbent vendor. In others, the way the arrangement has operated day to day invites questions about who the real employer was. This is not a conversation to start six weeks out, and not one to have without your own HR and legal advisers in the room.

The new provider starts from zero on knowledge that already existed. The incoming team is competent — that is why you hired them — but competence is not context. The first ninety days of a fresh on-site team are spent rebuilding a map that already existed, while the user population, who did not ask for any of this, experiences it as a service regression.

None of these are exotic risks. They are the ordinary, predictable consequence of treating a staffing question as a contracts question.

How we think about it: rebadging is a defined model, not an improvised HR conversation

The core observation is simple. The engineer and the contract are two different things, and only one of them is the reason you are switching.

Once you separate them, a third option appears that most transition plans never consider: transfer the engineers to the new provider's payroll. That is rebadging. Same person, same site, same users, new employer. The contract you wanted to leave ends. The knowledge you did not want to lose stays.

At Brocent this is not an ad hoc arrangement negotiated deal by deal. It is one of four defined engagement models for full-time on-site staffing, and it has a structured transition framework behind it:

• Type 1 — Fresh Hire. We run a systematic assessment of your IT environment needs, then propose the engineer level and service schedule, sourcing from our engineer pool. The right model when there is no incumbent team, or when the incumbent team is genuinely not what you want to keep.
• Type 2 — Rebadge. You already have on-site resource and want to change the main contractor while retaining the engineer. We run an HR assessment covering job level, social benefits and the service continuity plan.
• Type 3 — Hire to Budget. You have a defined IT service budget. We assess your needs against that budget and propose the optimal engineer level and service schedule that fits inside it.
• Type 4 — Hire for Change. You want to change an existing on-site service plan. We assess the impact of the change on service level, quality and the business, then propose an updated offering.

The reason the taxonomy matters is that it turns a question with no owner into a question with a defined answer. "What happens to the engineers?" stops being something nobody has standing to decide and becomes a selection between four models with different costs, timelines and consequences — a decision the company can actually make.

And it is worth being direct about the limits. Rebadging is not automatically the right answer. If the on-site team is genuinely underperforming, rebadging preserves the problem along with the knowledge. If you are switching vendors *because* of the people, a fresh hire is the honest choice. The point is not that rebadging always wins. The point is that it should be a decision rather than a default.

Three ways to handle the incumbent's on-site team

Let them go with the contract (the default)

• Requires no planning, which is exactly why it happens.
• All environment knowledge that was never written down leaves on the last day.
• Severance, notice periods and any joint-employment questions get handled reactively, under deadline pressure, usually by whoever is nearest.
• The new team's first quarter is spent rediscovering what the old team knew.
• Genuinely correct in one case: when the incumbent engineers are the reason you are switching.

Start entirely fresh with new hires

• A clean break, with no legacy assumptions or inherited habits.
• The right answer when the service model itself is changing, not just the vendor — a different skill mix, different coverage hours, different job levels.
• Costs the same knowledge as the default, but at least does so deliberately, with a planned onboarding rather than an accidental gap.
• Needs a real handover and documentation period budgeted into the timeline, not assumed into it.

A structured rebadging transition matched to your goal (the Brocent model)

• The same engineers continue on the same sites; the end-user population sees no change.
• Indicative end-to-end duration of three to four weeks, run as five phases plus a parallel replacement track.
• Each engineer's salary, benefits, location, role and notice period are validated before any offer goes out — compensation is finalised transparently, not imposed.
• The last working day with the incumbent employer is immediately followed by the joining day with the new one. That zero-gap switch is the design goal, not a hoped-for outcome.
• Engineers who decline to move are identified during validation and replaced in parallel, so one person's decision does not stall the programme.
• Payroll, statutory benefits, liability insurance, taxation and local labour-law compliance become the new provider's responsibility in every operating country.

What a rebadging transition actually involves

The framework runs in five phases with a sixth track in parallel. The indicative end-to-end duration is three to four weeks.

Phase 1 — Transition initiation (1–2 days). Formal approval to start. A draft change request is issued listing the in-scope resources. The resource list is frozen, including which engineer is allocated to which city and which site, and a tentative target start date is agreed. A daily governance call is established from day one, so that a slipping notice period or a missing document surfaces on the day it happens rather than at the deadline.

Phase 2 — Resource identification (2–3 days). Engineer names and contact details are shared. Where the incumbent cannot or will not share personal data — a normal and often entirely legitimate position — the framework uses an alternate route: a targeted recruitment drive, with the application link communicated to the identified engineers, who then apply directly. The outcome is the same without requiring the outgoing vendor to hand over anybody's personal information.

Phase 3 — Resource engagement and commercial validation (7–10 days). The longest phase, and the one that determines whether the commercials hold. Each engineer goes through a structured validation of current salary, benefits, location, job role and notice period. HR then calculates the fully loaded employment cost per person and reconciles the consolidated figure against the agreed commercial baseline. Where there is a variance, both parties review the affected resources jointly and agree the next step — a replacement, or a commercial re-submission. This is the mechanism that stops cost surprises from arriving after go-live.

Phase 3.1 — Replacements, in parallel (10–14 days). Some engineers will not move. A counteroffer from the incumbent, a compensation mismatch, a personal reason — it happens, and it is planned for rather than treated as a failure. Non-transitioning resources are flagged during validation, the client approves the replacement requirement, and sourcing runs in parallel with the main transition specifically so that it never extends the overall timeline.

Phase 4 — HR alignment and offer initiation (3–5 days). Compensation is finalised per candidate, and each engineer's willingness to transition and continue on the new payroll is explicitly confirmed, in line with the agreed commercials. Nobody is moved without having said yes.

Phase 5 — Offer release and onboarding (5–7 days). The change request is signed by both parties *before* any offer is released. Offers go out after document verification — salary slip and offer letter from the existing employer. Engineers accept, confirm the start date and resign from their current employer. Notice periods, resignation dates and joining dates are choreographed individually so that each switch lands on the agreed date. That choreography is the mechanism behind the zero-gap commitment: the last working day with the incumbent is immediately followed by the joining day with us.

Alongside all of this, the HR compliance work runs as standard: an NDA and project documentation signed before day one; background verification of identity, education and employment history; and payroll setup with statutory benefits enrolment and local labour-law compliance — including liability insurance and taxation — owned in every operating country.

Two governance details are worth calling out, because they are what separate a framework from a plan. The first is the daily call, running from day one rather than at milestones. The second is commercial variance control: every engineer's fully loaded employment cost is validated against the baseline *before* offers go out, so a cost gap is a decision point during the transition rather than a discovery after it.

Where rebadging sits in a wider managed IT decision

It is worth putting this in proportion. Rebadging is a transition mechanism, not a service model. It answers the question *how do we get from the current arrangement to the next one without breaking anything*. It does not, by itself, answer the more important question of what the next arrangement should be.

For most companies the substantive decision is the shape of the managed IT plan — what is covered, how it is priced, what is measured, who is accountable at the account level. On-site staffing is one component of that. If a vendor change is on the table at all, the useful sequence is to settle the service model first and the transition mechanics second. Our managed IT support plans and the pricing behind them are where that first conversation belongs; full-time on-site IT support describes how dedicated engineers fit into it, and the resource rebadging and transition framework sets out the mechanism above in full, including the phase-by-phase RACI.

One practical note on cost. On-site engineer pricing is not a single number, and anyone who quotes one without asking questions is guessing. The real drivers are contract duration, job level and specialist skills, years of relevant experience, working language, the coverage window, the site location, whether a backfill resource is required during leave, how client holidays are treated — and, relevant here, the resource type itself. Fresh Hire, Rebadge, Hire to Budget and Hire for Change each carry different set-up and transition costs. Rebadging is not automatically cheaper or more expensive than hiring fresh; it is a different cost shape, and it should be priced as one.

Frequently asked questions

What is IT rebadging?

IT rebadging is the transfer of existing on-site IT engineers from one employer to another — typically from an outgoing outsourcing vendor to the incoming one — while those engineers continue working at the same sites, supporting the same users and the same systems. The contract changes and the employer changes; the person and the assignment do not.

Does rebadging mean the same people definitely keep their jobs?

It means they are offered the opportunity, not that the outcome is guaranteed. Each engineer's compensation is validated and finalised, and their willingness to transition is confirmed before any offer is released. An engineer can decline — because of a counteroffer from the incumbent, a compensation mismatch, or a personal reason — and that possibility is planned for through a parallel replacement track rather than treated as an exception.

What happens to severance obligations with the outgoing vendor?

That depends on the jurisdiction, on the contract between the company and the incumbent vendor, and on how the employment relationship was actually structured in practice — which is precisely why it should not be worked out six weeks before a cutover. A rebadging transition is designed to make this a planned item: notice periods, resignation dates and joining dates are individually choreographed per engineer as part of the framework. Your own legal and HR advisers should confirm the position in each operating country; the transition framework supplies the sequencing, not the legal opinion.

What is the difference between Rebadge, Fresh Hire, Hire to Budget and Hire for Change?

Rebadge retains existing engineers under a new contractor. Fresh Hire sources new engineers against an assessment of your requirements. Hire to Budget works backwards from a defined budget to the optimal engineer level and schedule. Hire for Change adapts an existing on-site plan when the requirement itself has shifted. They are four answers to four different situations, and they carry different set-up and transition costs.

Does this work the same way in every country?

The framework and the sequence are the same everywhere, and that is deliberate — a multi-country transition run as one governed programme is far easier to control than four local ones running to their own rhythms. What differs is the local employment layer underneath it: notice periods, statutory benefits, severance mechanics and social-insurance enrolment are country-specific, and they are handled as a country-specific responsibility of the new employer rather than a shared improvisation.

How long does a rebadging transition take?

The indicative end-to-end duration is three to four weeks. The longest single phase is resource engagement and commercial validation, at seven to ten days. Replacement management runs ten to fourteen days but deliberately runs in parallel, so it does not extend the overall timeline.

What if the incumbent vendor refuses to share engineer details?

This is common and often entirely proper, since the incumbent holds that personal data as the current employer. The framework includes an alternate engagement mechanism for exactly this case: a targeted recruitment drive where the application link is communicated to the identified engineers, who apply directly. The transition proceeds without the outgoing vendor having to hand over anybody's personal data.

Is rebadging always the right choice?

No. If the on-site engineers are the reason you are changing vendors, rebadging preserves the problem. If the service model itself is changing — different skill levels, different coverage hours, a different mix of roles — a fresh hire or a hire-for-change model is more honest. Rebadging is the right answer when the contract is what you want to leave and the people are what you want to keep.

Where to start

If a vendor change is in front of you and the people question has not been answered, the first useful step is not a decision about rebadging. It is putting the question on the plan, with an owner and a date, early enough that all three options are still open. Six weeks out, they usually are not.

From there, settle the service model — what the managed IT plan actually covers and what it costs — before settling the transition mechanics. If you want to walk through how a transition would sequence against your own sites and notice periods, get in touch and we will map it against the real phases rather than a generic timeline.