What Is Build Operate Transfer? The BOT Model Explained
Build Operate Transfer (BOT) is a contractual IT delivery model in which a specialist provider establishes an offshore or nearshore engineering team on behalf of a client company, manages that team through an operational period under the client's direction, and then transfers full ownership of the team — its people, infrastructure, and institutional knowledge — to the client at a pre-agreed point in time.
The model is used by companies that want to build a permanent offshore engineering capability without taking on the full legal, operational, and recruitment burden of establishing a foreign subsidiary from day one. The provider absorbs setup risk and management overhead during the early period; the client inherits ownership as the team matures.
This guide covers how the BOT model works, where it came from, what distinguishes it from other delivery models, and what the commercial and legal structure looks like.
The Origin of BOT
The Build Operate Transfer model did not originate in the IT industry. It was developed in the 1980s and 1990s as a financing and governance mechanism for large public infrastructure projects — highways, airports, power stations, water treatment plants — in developing economies.
Governments in Southeast Asia, the Middle East, and Latin America needed infrastructure that public budgets could not fund directly. The BOT solution: private companies — often consortia of construction firms and banks — would finance, build, and operate the infrastructure for a defined concession period, recovering their investment through usage fees or government payments. At the end of the concession, the fully operational asset transferred to the state.
The IT adaptation of BOT emerged in the early 2000s as Western companies began establishing offshore development centers in India, Eastern Europe, and the Philippines. The parallel was direct: instead of building a highway and transferring it to a government, a provider builds an engineering team and transfers it to a corporation. In both cases, the provider manages the complexity of establishment; the client inherits a functioning operation rather than building it from scratch.
Today, Build Operate Transfer is a standard delivery model in IT outsourcing, used by companies ranging from mid-market software firms to Fortune 500 enterprises establishing global capability centers.
The Three Phases in Detail
Phase 1: Build
The Build phase covers the establishment of the offshore team from contract signature to full operational readiness.
Duration: Typically 3–6 months, depending on team size, delivery country, and complexity of technical requirements.
What happens:
The provider recruits, screens, and hires engineers and supporting staff to the client's specifications. Hiring decisions require client approval — job descriptions, seniority levels, and individual hire approvals are all agreed jointly. This is what distinguishes BOT from outsourcing: the client builds the team specification; the provider executes it.
Simultaneously, the provider establishes the operational infrastructure: office space, IT environment, network configuration, security controls, and the management layer (a delivery manager or country manager who will run the operational side during the Operate phase).
The provider also implements the client's technical environment: version control, CI/CD pipeline, development standards, communication tools, ticketing systems, and security policies. By the end of the Build phase, the team is working in the client's environment under the client's technical standards — not the provider's.
Key milestone: Client sign-off on full operational readiness. The SLA clock starts. The Operate phase begins.
Client obligations during Build:
- Define hiring criteria and approve candidates
- Provide technical environment specifications and access for configuration
- Appoint an internal liaison (engineering manager or VP) as the primary contact
- Participate in governance design (KPIs, reporting, escalation paths)
Phase 2: Operate
The Operate phase is the commercial heart of the BOT engagement. The provider manages the team operationally while the client directs the work.
Duration: Typically 18–36 months. Shorter Operate phases (under 18 months) reduce the economic case for the model; longer phases (over 36 months) are used for larger teams or more complex operational setups.
Division of responsibility:
| Responsibility | Client | Provider |
|---|---|---|
| Technical direction and product decisions | ✅ | |
| Sprint planning and delivery management | ✅ | |
| Performance management (technical) | ✅ | |
| HR, payroll, and employment compliance | ✅ | |
| Office and infrastructure management | ✅ | |
| Recruitment and onboarding for growth | ✅ | |
| Local regulatory compliance | ✅ | |
| Reporting and governance operations | Both | Both |
The Operate phase is not outsourcing in the traditional sense. The client directs all technical work. The provider is the employer of record and manages people operations. The separation between technical management (client) and people operations (provider) is the structural logic of the model.
Team growth during Operate: Most BOT contracts allow for headcount growth during the Operate phase. Growth requires a defined notice period (typically 4–8 weeks for a senior hire), is subject to the same approval process as the initial Build, and is priced at the same per-head commercial terms.
What is being built during Operate: Beyond delivering technical work, the Operate phase builds institutional knowledge — the team's deep familiarity with the client's product, codebase, architecture, and business domain. This accumulated knowledge is what makes the team valuable at Transfer. A team that has operated for 30 months is fundamentally more valuable than a newly assembled team of the same size.
Phase 3: Transfer
The Transfer phase converts the provider-managed team into a client-owned operation.
Duration: Typically 3–6 months of execution, with planning beginning 6 months before the Transfer date.
What transfers:
- Employment contracts: Novated from the provider's legal entity to the client's local subsidiary. Each team member's employment terms are preserved; the employer changes.
- Office lease: Assigned to the client's entity or re-signed in the client's name.
- Equipment: Transferred at depreciated value or re-purchased by the client.
- Software licenses and tooling: Reassigned or re-procured by the client.
- Operational documentation: Runbooks, process documentation, org charts, HR policies, vendor relationships — delivered as a formal handover package.
- Recruitment pipelines and HR data: Active candidate pipelines, performance history, compensation data transferred to the client's HR function.
- IP confirmation: Formal schedule confirming client ownership of all work product (should already be assigned under the MSA, but confirmed explicitly at Transfer).
What does not transfer: The provider's own business, IP, or client relationships. The provider exits this engagement. They may continue working with the client in other capacities, but the BOT team is no longer their operational responsibility.
Post-Transfer: The client becomes the direct employer, the leaseholder, and the operational manager of the team. Costs drop from "staff cost + provider margin" to "direct employment cost + internal overhead." This is the economic payoff of the model.
What Makes BOT Different
The BOT model is frequently confused with adjacent models. The distinctions matter because they determine who owns what, who is accountable for what, and what the long-term cost structure looks like.
BOT vs Outsourcing: In outsourcing, the provider owns and manages the delivery team permanently. The client receives output, not a managed team, and has no path to ownership. BOT terminates the provider relationship on a defined date and transfers the team to the client.
BOT vs Staff Augmentation: Staff augmentation places individuals into the client's existing team under direct client management. The provider supplies people; the client supplies the management layer. BOT builds a complete team unit with its own management structure, operated by the provider during the Operate phase, with a path to client ownership. Staff augmentation has no transfer mechanism.
BOT vs Dedicated Team: A dedicated team is exclusively assigned to one client but remains the provider's team indefinitely. BOT is structurally the same during the Operate phase, then diverges: the provider exits and the team becomes the client's own at Transfer.
BOT vs Captive Center: A captive center is a wholly-owned offshore subsidiary established directly by the client. It reaches the same end state as BOT Transfer — a company-owned team — but the client absorbs all setup risk, legal cost, and operational management from day one. BOT uses the provider's infrastructure to reach the same destination with lower upfront exposure.
The BOT Commercial Model
BOT engagements are priced across three commercial phases:
Build phase: Fixed setup fee covering legal, recruitment, infrastructure, and management costs during establishment. Typical range: €15,000–€80,000 for a 10–20 person team, depending on delivery country, role seniority, and provider.
Operate phase: Monthly per-head fee per team member. This covers:
- Direct employment cost (gross salary + employer-side statutory contributions)
- Provider management margin (typically 12–20%)
- Office and infrastructure cost allocation
Transfer: One-time Transfer fee, typically 1–3 months of the operating fee. Covers provider's transition costs, knowledge transfer activities, and exit administration.
Post-Transfer cost: Direct employment cost + internal overhead. Provider margin eliminated. Total ongoing cost typically 20–35% lower than the Operate-phase per-head rate.
The economic case for BOT depends on the client reaching the Transfer phase. Companies that terminate before Transfer pay setup and operating fees without capturing the long-term cost reduction. The minimum engagement horizon for BOT to be economically justified is typically 24–30 months.
BOT Governance Structure
A well-governed BOT engagement has three governance layers:
Strategic governance (quarterly): Client C-suite / VP level and provider account management. Covers: overall engagement health, Transfer timeline, commercial review, strategic changes to scope.
Operational governance (monthly): Client engineering leadership and provider delivery manager. Covers: SLA performance, headcount status, attrition, recruitment pipeline, upcoming milestones, budget vs actual.
Delivery governance (weekly): Client engineering team and offshore team leads. Covers: sprint velocity, blockers, technical decisions, day-to-day coordination.
The provider owns operational governance as a service obligation. The client owns delivery governance. Strategic governance is shared. This three-tier structure is what prevents BOT from becoming either unmanaged outsourcing (no oversight) or micromanaged staff augmentation (excessive client overhead).
BOT Terminology Glossary
| Term | Definition |
|---|---|
| Build phase | The establishment period; provider recruits, sets up infrastructure, and reaches full headcount |
| Operate phase | The operational period; provider manages people operations, client directs technical work |
| Transfer phase | The handover period; ownership of team, office, and assets moves to the client |
| Transfer date | The agreed date or trigger event on which Transfer commences |
| Novation | Legal mechanism by which employment contracts are transferred from one employer to another |
| SLA (Service Level Agreement) | Provider obligations on people operations: attrition, headcount replacement, reporting |
| Per-head rate | Monthly fee per team member during the Operate phase |
| Employer of Record (EOR) | Legal employer during the Operate phase — typically the provider's local entity |
| Transfer fee | One-time payment at Transfer, compensating the provider for transition cost |
| Captive center | Wholly-owned offshore subsidiary; same end-state as BOT Transfer but different path |
| ODC (Offshore Development Center) | A facility-based team dedicated to one client; may be established via BOT or other models |
| GCC (Global Capability Center) | Large-scale offshore or nearshore center covering multiple functions; often the destination of a multi-year BOT |
BOT for Enterprise Platform Teams
BOT is not a generic offshore team model. When the offshore capability being built is a permanent, specialised function centred on an enterprise technology platform, BOT's structure — a defined team, built to client specification, operating under client direction, with a contractual path to client ownership — fits more precisely than any alternative. The key criterion for fit is permanence: if the platform function is an ongoing capability rather than a project, BOT is structurally correct. If it is a time-limited implementation, a dedicated team model or staff augmentation is more appropriate.
Enterprise platforms require a permanent, specialised workforce. They are not project technologies. SAP, Oracle, Salesforce, and the cloud hyperscalers all generate continuous operational and development demand that outlasts any individual project. The team that supports them is a standing function, not a project assignment. BOT's Operate phase, which builds institutional knowledge over 18–36 months, is structurally aligned to this requirement. For detailed operational mechanics of how these centres are structured, governed, and priced, see the BOT model operational guide.
SAP: Which Enterprises Qualify for the BOT Model
SAP-dependent enterprises that qualify for the BOT model share a specific characteristic: their SAP estate generates continuous, multi-year operational demand that cannot be satisfied by project-rate contractors. The skills required to run and evolve a complex SAP estate — BASIS administration, ABAP development, functional configuration across finance, logistics, and production — are concentrated in an ageing workforce in Western Europe and increasingly hard to hire locally.
A BOT IT delivery center for SAP functions gives the enterprise a client-directed team of SAP specialists in a delivery country where the talent pool remains deep: Romania, Poland, and India each have significant concentrations of SAP-certified professionals. The BOT structure keeps upgrade cycles, patch management, and enhancement projects inside the centre rather than sourced from system integrators on project rates. This approach differs from staff augmentation in one structural respect: the institutional knowledge of your specific SAP configuration — the customisations, the data model decisions, the known edge cases — stays in the centre and transfers to the client at the end of the Operate phase.
Typical roles: SAP Basis Administrator, ABAP Developer, SAP Functional Consultant (FI/CO, MM, SD, PP, PM), SAP BTP Developer, SAP Fiori/UX Developer, SAP BW/BI Developer, SAP Security Consultant.
Salary reference (Romania, gross monthly): SAP Basis Administrator €4,500–€7,000; ABAP Developer €4,000–€6,500; SAP Functional Consultant (senior) €3,800–€6,500. Equivalent roles in Germany run 80–120% higher.
Oracle
Oracle EBS and Oracle Fusion estates are long-lived by nature. A manufacturing company that implemented Oracle EBS in the early 2000s may still be running it today — with significant customisation built up over two decades. The engineers who understand that customisation are the system's most valuable asset. A BOT IT delivery center keeps those engineers in a stable, client-owned structure rather than cycling them through project-based contracting.
Typical roles: Oracle DBA, Oracle Fusion Functional Consultant (Finance, Supply Chain, HCM), PL/SQL Developer, Oracle Cloud Infrastructure (OCI) Engineer, Oracle Integration Cloud (OIC) Developer, Oracle APEX Developer.
Salesforce: Fit Criteria for a BOT Center of Excellence
A Salesforce center of excellence via BOT is appropriate when the Salesforce estate has grown beyond what a single administrator or generalist developer can manage, and when the organisation needs layered expertise — Apex development, architecture governance, release management, and certification maintenance — in a stable, client-directed structure. Salesforce Centres of Excellence represent one of the most active BOT use cases in 2024–2025, driven by the platform's expansion into AI (Agentforce), data (Data Cloud), and industry-specific clouds.
Certifications are a practical concern: Salesforce maintains certification relevance through annual release cycles. A BOT centre houses those certifications in a stable team where renewal and upskilling are managed organisationally, rather than scattered across contractors whose certifications may lapse between engagements. This is a structural advantage over staff augmentation that does not disappear at Transfer — the client inherits a centre with active, maintained certifications.
Typical roles: Salesforce Administrator, Apex Developer, Lightning Web Component (LWC) Developer, Salesforce Architect (Application or System Design certified), Marketing Cloud Specialist, Salesforce Data Cloud Engineer, CPQ Specialist.
Microsoft
For enterprises standardised on the Microsoft technology stack, the scope of ongoing technical work is broad: Azure infrastructure operations, Microsoft 365 administration, Power Platform development (Power Apps, Power Automate, Power BI, Copilot Studio), and Dynamics 365 implementation and support. Each of these is a substantial function in a large organisation; together, they justify a dedicated IT delivery center.
Typical roles: Azure Cloud Engineer (AZ-900 through AZ-305 certified), Microsoft 365 Administrator, Azure DevOps Engineer, Power Platform Developer, Dynamics 365 Functional Consultant (Finance & Operations, Customer Engagement), Microsoft Sentinel Security Engineer.
Hyperscalers (AWS, GCP, Azure)
Cloud platform engineering centres — built for companies running significant workloads on one or more of the major cloud providers — are among the technically deepest BOT engagements. The work is not deployment; it is the ongoing operation, optimisation, and governance of complex cloud infrastructure: multi-account landing zones, internal developer platforms, FinOps programmes, and Kubernetes-based workload orchestration.
Typical roles: Cloud Architect (AWS Solutions Architect Professional, GCP Professional Cloud Architect, or Azure Solutions Architect Expert certified), Site Reliability Engineer (SRE), Platform Engineer, FinOps Analyst, Kubernetes/Container Operations Engineer, Terraform/Infrastructure-as-Code Specialist.
The Structural Case Against Staff Augmentation for Platform Teams
Staff augmentation does not accumulate institutional knowledge. When a Salesforce architect or SAP Basis engineer is a contractor rotating across multiple clients, the deep knowledge of your system's customisations, technical decisions, and data model is not retained — it leaves with the individual. A BOT IT delivery center keeps that knowledge inside a team that has no other client. Certifications are maintained at the centre level. Upgrade cycles are absorbed by the centre. At Transfer, the client owns not just the employment contracts but the collective institutional memory of every engineer who has worked on their platform.
For a full comparison of BOT against staff augmentation across all dimensions — cost, speed, risk, and knowledge retention — see BOT vs staff augmentation.
Industries and Use Cases
BOT is not sector-specific. It is used wherever a company needs a permanent offshore engineering or operations capability. Common applications:
Product engineering: Scaling a software product team with a dedicated offshore unit — same product, same codebase, same sprint cadence.
SAP and ERP platforms: Establishing a dedicated team for ongoing SAP implementation, support, and development. The long lifecycle of SAP programs makes BOT's multi-year structure appropriate.
Data and analytics platforms: Building a data engineering or analytics center of excellence offshore, with the intent to make it a permanent capability.
Finance shared services: Establishing an offshore finance processing or controllership function that will eventually operate as part of the company's finance organisation.
Customer operations: Building nearshore customer support or operations centers with the intent to integrate them into the company's operating structure.
Cybersecurity and compliance: Dedicated security operations centers built via BOT for companies that need 24/7 coverage at a cost point that European-only staffing cannot achieve.
BOT Model Advantages
Managed setup risk: The provider absorbs the complexity of establishing operations in an unfamiliar country — legal, HR, office, recruitment — during the Build phase. The client inherits an operational team, not a greenfield problem.
No permanent margin: Unlike outsourcing, where provider margin is permanent, BOT margin expires at Transfer. The post-Transfer cost structure is direct employment, which is structurally cheaper.
Team cohesion: The team is built as a unit for one client. Cohesion and institutional knowledge accumulate over the Operate phase. This is the opposite of staff augmentation, where individuals cycle through.
Regulatory navigation: Employment law, tax compliance, and regulatory requirements in the delivery country are the provider's obligation during the Operate phase. This is particularly valuable when entering a jurisdiction where the client has no prior operational experience.
Clear ownership path: BOT is the only delivery model with an explicit path to the client owning the team. This is contractually defined at the start, not negotiated later.
BOT Model Risks and Limitations
Minimum viable horizon: BOT does not pay off in short engagements. Companies that terminate before the Transfer crossover point (typically Month 24–30) pay setup and operating costs without capturing the economic benefit.
Transfer execution risk: Transfer is complex. Employment contract novation, lease assignment, equipment transfer, and IP confirmation require coordination across legal teams in at least two jurisdictions. Poorly planned Transfers delay or fail. This is the most common point of failure in BOT engagements.
Provider dependency: During the Operate phase, the provider controls the team's people operations. A provider that manages attrition poorly, hires below standard, or becomes financially unstable creates problems for the client. Provider selection and ongoing governance are the primary risk mitigants.
Not suitable for small teams: The governance and legal overhead of BOT is not economically justified for teams below 8–10 people. Smaller teams are better served by dedicated team arrangements or staff augmentation.
Requires client readiness to be an employer: Transfer only works if the client establishes legal employer status in the delivery country. Companies that are not prepared to incorporate and operate as an employer in the delivery country cannot execute a Transfer and should not enter a BOT contract.
Frequently Asked Questions
What does BOT stand for in IT outsourcing?
BOT stands for Build Operate Transfer. In IT outsourcing, it refers to the three-phase delivery model in which a provider builds an offshore team (Build), manages it operationally while the client directs the work (Operate), and hands ownership of the team to the client at a defined point (Transfer).
How long does a Build Operate Transfer engagement take?
A full BOT engagement — from contract signature to Transfer completion — typically takes 2.5–4 years. The Build phase runs 3–6 months, the Operate phase 18–36 months, and the Transfer phase 3–6 months. Shorter engagements are possible but reduce the economic justification for the model.
What is the difference between BOT and BPO?
BPO (Business Process Outsourcing) refers to contracting a provider to deliver a business function — finance, HR, customer service — as a managed service, typically with no path to ownership. BOT is a delivery model where the client retains technical direction of the team and owns the team at Transfer. BPO prioritises output; BOT prioritises capability building and eventual ownership.
Who uses the Build Operate Transfer model?
BOT is used by mid-market and enterprise companies across technology, finance, manufacturing, and professional services. Common users include: software companies scaling product engineering, SAP-dependent enterprises building dedicated support and development teams, and large corporations establishing global capability centers.
Is BOT the same as a global capability center?
A Global Capability Center (GCC) is a large-scale offshore or nearshore center — typically 100+ people — covering multiple business functions. BOT is a contractual model, not a center type. GCCs are often established via BOT, particularly in their early phases. As the center grows and matures, the BOT structure may be replaced by a full captive operation.
What countries are most commonly used for BOT engagements?
India is the largest BOT market by volume. Eastern Europe — Romania, Poland, Czech Republic, Ukraine — is preferred by Western European buyers for time zone alignment, EU membership, and GDPR compliance. Southeast Asia (Philippines, Vietnam) is growing for specific skill profiles and US-timezone coverage.
Can a BOT model be used to build a Salesforce center of excellence?
Yes. A Salesforce center of excellence is one of the fastest-growing BOT use cases. The Salesforce platform — Sales Cloud, Service Cloud, Marketing Cloud, Data Cloud, Agentforce — requires a team with layered, continuously maintained expertise, not a single contractor. BOT builds this team in a delivery country with Salesforce-certified talent, maintains certifications organisationally during the Operate phase, and transfers full ownership to the client. The result is a centre where Apex developers, LWC specialists, architects, and Marketing Cloud engineers work under the client's direction with no other client. Staff augmentation cannot replicate this structure: certifications lapse, knowledge leaves, and there is no Transfer.
Is COBOL development available through BOT engagements in Eastern Europe?
Yes. Romania, Poland, and Ukraine retain meaningful concentrations of COBOL-proficient engineers — a consequence of those markets' engineering education cycle, which overlapped with the period when COBOL was still the standard for enterprise systems. A BOT IT delivery center in Bucharest or Krakow can build a team of COBOL programmers for mainframe-dependent banks, insurance companies, and government agencies. The BOT model is particularly suited to this use case because it enables gradual, structured knowledge transfer from ageing internal specialists to a stable, client-directed offshore team — rather than the enterprise relying on a diminishing pool of local contractors.
Key Takeaways
- Build Operate Transfer is a three-phase model: the provider builds the team, manages it operationally, then transfers ownership to the client
- The model originated in infrastructure project finance and was adapted for IT in the early 2000s
- BOT is the only delivery model with an explicit, contractually-defined path to the client owning the team
- The Operate phase division is clear: client directs technical work, provider manages people operations
- BOT makes economic sense for teams of 10+ people on a horizon of 24+ months
- Transfer is the most complex phase and requires planning 6 months in advance
- Post-Transfer, the client's cost drops to direct employment cost — provider margin is eliminated