The Build Operate Transfer Model: How It Works in Practice

KPI	Definition	Notes
Sprint velocity	Story points delivered per sprint	Baseline established in Month 3
Defect rate	Defects per release as % of features shipped	Trended, not fixed target
Code review coverage	% of PRs reviewed before merge	Client-set standard
Deployment frequency	Releases per month	Client-set standard
Onboarding time	Days for new hire to first meaningful contribution	Used to assess knowledge transfer quality

Important: Delivery KPIs are tracked jointly but accountability sits with the client, not the provider. The provider delivers the team; the client directs the work. If sprint velocity is low, the root cause may be scope clarity, not team capability.

Pricing Structure: How BOT is Costed

Build Phase Pricing

Build phase fees are typically fixed or milestone-based, covering:

• Recruitment costs: Usually 10–15% of first-year salary per hire, or a fixed per-head fee
• Legal and entity setup: If the provider is establishing a new structure for this engagement
• Office setup: Fit-out, equipment procurement, network configuration
• Management overhead: Provider delivery manager time during the Build phase

Typical total Build phase cost for a 15-person team: €30,000–€100,000, depending on country, seniority profile, and how much infrastructure the provider is building from scratch vs leveraging existing.

Operate Phase Pricing

The per-head monthly rate is built from four components:

`` Per-head monthly rate = Gross salary (market rate for role and seniority) + Employer statutory contributions (country-specific, typically 2–35% of gross) + Office and infrastructure allocation (per-head share of shared costs) + Provider management margin (12–20%) ``

Example (senior software engineer, Romania):

• Gross salary: €4,500/month
• Employer contributions (Romania): ~€100/month
• Office allocation: ~€200/month
• Provider margin (20%): ~€960/month
• Total per-head rate: ~€5,760/month

vs. direct employment post-Transfer:

• Gross salary: €4,500/month
• Employer contributions: ~€100/month
• Internal overhead allocation: ~€300/month
• Total direct cost: ~€4,900/month (~15% lower)

For a 15-person team, this difference compounds to approximately €126,000/year in savings post-Transfer.

Transfer Pricing

Transfer fee: typically 1–3 months of total operating fees. For a 15-person team at the example above, this is €87,000–€260,000 — a one-time cost that is typically recovered within 18–24 months of post-Transfer savings.

Asset buyout: equipment transferred at net book value (typically 20–30% of purchase price for assets 2–3 years old). Often a minor component compared to the Transfer fee.

The Build Phase: Operational Detail

Week 1–2: Engagement Kickoff

• Delivery manager assigned by provider
• Client liaison confirmed
• Governance framework agreed (cadence, participants, reporting templates)
• Delivery country and city confirmed
• Legal and employment structure confirmed

Week 2–6: Infrastructure and Recruitment Launch

• Office location confirmed or secured
• Job descriptions finalised with client input
• Salary bands agreed per role
• Active recruitment begins (job boards + direct outreach)
• IT infrastructure procurement initiated
• Client-side onboarding process designed (VPN access, tooling credentials, communication channels)

Week 4–14: Hiring Waves

Senior roles take longer to fill than junior roles. Most Build phases run in hiring waves:

• Wave 1: Team lead(s) and senior engineers (critical path — these are the culture carriers)
• Wave 2: Mid-level engineers
• Wave 3: Supporting roles (QA, DevOps, BA)

Each hire requires client approval before offer is extended. A 48–72 hour client response SLA for hire approvals should be written into the governance framework — slow approvals on the client side are the most common cause of Build phase delays.

Month 3–5: Operational Readiness

• Full headcount (or agreed milestone headcount) reached
• Client tooling and infrastructure fully configured
• First sprint completed
• Baseline delivery KPIs established
• SLA framework live
• Formal Build phase sign-off executed

The Operate Phase: Day-to-Day Running

The Provider's Daily Responsibilities

During the Operate phase, the provider's delivery manager is running an HR and operations function, not a delivery function. Day-to-day provider activities include:

• Payroll processing and statutory reporting
• Absence and leave management
• Performance review administration (aligned with client standards)
• Recruitment pipeline management (backfill and growth)
• Office management (facilities, IT support, vendor relationships)
• Monthly operational reporting to client
• Local regulatory compliance (employment law updates, tax filings, health and safety)

The Client's Daily Responsibilities

• Technical direction via sprint ceremonies
• Code review and quality standards
• Architecture and product decisions
• Performance feedback on technical output (fed to provider for HR administration)
• Approval of new hire recommendations
• Approval of salary review outcomes above the agreed annual index

Salary Review Process

Annual salary reviews in BOT engagements follow a defined process:

1. Provider benchmarks current salaries against updated market data
2. Provider proposes increases per individual, within the agreed indexation cap
3. Client reviews and approves (or contests with alternative data)
4. Provider administers the increase
5. Per-head rates are updated accordingly

Clients who delegate this entirely to the provider risk salary drift above budget. Clients who micromanage it lose the provider's local market expertise. The right model is provider-proposed, client-approved, with a defined cap that requires escalation if exceeded.

The Transfer Phase: Execution Mechanics

6 Months Before Transfer Date

• Client establishes local legal entity (if not already in place)
• Transfer project plan agreed between client and provider
• Employment contract templates prepared for novation
• Asset inventory compiled and valued
• Lease assignment or new lease negotiated

3 Months Before Transfer Date

• Individual transfer meetings with each team member (provider and client HR present)
• New employment offer letters issued by client entity
• Any retention bonuses or incentives offered by client confirmed
• Software license reassignment initiated
• Data migration and platform access planning

Transfer Month

• Employment contract novation executed (typically all on the same date)
• Lease assignment completed
• Equipment title transferred
• Provider operational handover: vendor contacts, payroll data, HR files, operational runbooks
• IP confirmation schedule executed
• Provider management layer exits

Post-Transfer (Month 1–3)

• Client's country manager or regional HR takes over people operations
• Former provider delivery manager may serve in an advisory capacity for 30–60 days (contractual option)
• Any post-Transfer issues tracked against the Transfer warranty provisions in the contract

Technology and Infrastructure Model

The BOT team operates in the client's technical environment, not the provider's. This is a non-negotiable design principle. Provider-managed tooling that embeds itself into the team's workflow creates dependency that complicates Transfer.

Client-owned and configured:

• Source control (GitHub, GitLab, Bitbucket)
• CI/CD pipeline
• Issue tracking (Jira, Linear, Azure DevOps)
• Communication (Slack, Teams)
• Cloud infrastructure (AWS, Azure, GCP accounts)
• Secrets management and credentials

Provider-managed:

• Local network and office IT
• Physical security
• End-user devices (typically provider-procured, client-spec, transferred at Transfer)
• Local IT support

Security perimeter: The BOT team operates inside the client's security perimeter via VPN or zero-trust network architecture. Data residency requirements (particularly relevant for EU clients with GDPR obligations) should be documented in the infrastructure agreement during Build.

BOT for Enterprise Platform Teams

The enterprise platform BOT model applies where the offshore capability is a permanent, specialised function centred on an enterprise technology platform. SAP, Oracle, Salesforce, Microsoft, and the major cloud hyperscalers share a structural characteristic that makes BOT particularly well-suited: they require a permanent, specialised workforce to operate and evolve. These are not project skills. They are ongoing operational capabilities that degrade when the people who hold them leave. BOT is a natural fit for companies building dedicated IT delivery centers around these platforms, because the centre becomes the institutional home of that expertise. For more on the case for BOT over staff augmentation for these platforms, see what is Build Operate Transfer and the BOT advantages analysis.

SAP Offshore Development Center

A SAP offshore development center built via the BOT model gives SAP-dependent enterprises a permanent, client-directed team that absorbs upgrade cycles internally rather than relying on rotating system integrator contractors. SAP programs are multi-year by definition. Whether the trigger is an S/4HANA migration, a RISE with SAP transition, or ongoing ABAP development for a customised ERP estate, the work does not end at go-live — it extends into continuous support, enhancement, and upgrade cycles. Romania has particular depth in SAP-certified professionals; see the offshore development center in Romania guide for talent availability and salary benchmarks.

Typical roles built in a BOT SAP centre: SAP Basis Administrator, ABAP Developer, SAP Functional Consultant (FI/CO, MM, SD, PP, PM), SAP BTP Developer, SAP Fiori/UX Developer, SAP Security Consultant, SAP BW/BI Developer.

Salary reference (Romania, gross monthly): SAP Functional Consultant €3,800–€6,500; ABAP Developer €4,000–€6,500; SAP Basis €4,500–€7,000. These roles are increasingly difficult to source in Western European markets where SAP talent competes with higher-compensation sectors.

Oracle

Oracle Fusion and EBS implementation and support centres follow similar dynamics. Finance and procurement transformations on Oracle Fusion are long-cycle programs; Oracle EBS estates in manufacturing, utilities, and public sector often run for 15+ years. A BOT IT delivery center for Oracle functions preserves the institutional knowledge of a complex, customised system that would otherwise leave with contractors at the end of each engagement.

Typical roles: Oracle DBA, Oracle Fusion Functional Consultant (Finance, Supply Chain, HCM), PL/SQL Developer, Oracle Cloud Infrastructure (OCI) Engineer, Oracle Integration Cloud Developer.

Salesforce Center of Excellence

A Salesforce center of excellence established via BOT concentrates the full range of platform expertise — Apex development, LWC, architecture governance, release management, and certification maintenance — in one client-directed team. The Salesforce platform's breadth — Sales Cloud, Service Cloud, Marketing Cloud, Data Cloud, Agentforce — means that a mature Salesforce estate requires a team, not an individual. Configuration, Apex and LWC development, architecture governance, and release management are continuous functions.

Typical roles: Salesforce Administrator, Apex Developer, Lightning Web Component (LWC) Developer, Salesforce Architect (certified), Marketing Cloud Specialist, Salesforce Data Cloud Engineer. Salesforce certifications are maintained more reliably when they sit within a centre than when they are distributed across contractors who hold them individually.

Microsoft

Azure infrastructure, Microsoft 365 administration, Power Platform development, and Dynamics 365 implementation are increasingly running as dedicated IT delivery centres for enterprises standardised on the Microsoft stack. The Power Platform alone — Power Apps, Power Automate, Power BI, Copilot Studio — now generates enough workflow development demand in large organisations to justify a permanent team.

Typical roles: Azure Cloud Engineer, Microsoft 365 Administrator, Azure DevOps Engineer, Power Platform Developer, Dynamics 365 Functional Consultant (Finance & Operations, Customer Engagement), Security Engineer (Microsoft Sentinel, Defender).

Azure Offshore Engineering Team (and AWS / GCP)

An Azure offshore engineering team — or its AWS or GCP equivalent — is the most technically complex BOT use case. Building and operating cloud infrastructure at enterprise scale — multi-account landing zones, FinOps programmes, platform engineering for internal developer platforms, Kubernetes cluster operations — requires a team of senior engineers whose expertise is continuously developed, not rotated. A BOT cloud engineering centre retains that expertise internally; staff augmentation scatters it across contractors who leave when the project closes.

Typical roles: Cloud Architect (AWS/GCP/Azure certified), Site Reliability Engineer (SRE), Platform Engineer, FinOps Analyst, Kubernetes Engineer, Terraform/Infrastructure-as-Code Specialist, Security Engineer (cloud-native tooling).

Why BOT Outperforms Staff Augmentation for Platform Teams

The structural argument against staff augmentation for enterprise platform teams is that institutional knowledge does not accumulate. When an ABAP developer or Salesforce architect is a contractor cycling through multiple clients, their knowledge of your system's specific customisations, data model decisions, and technical debt leaves with them. A BOT IT delivery center keeps that knowledge in one place, under your direction, building depth over the Operate phase. At Transfer, you do not just get the team — you get the collective system knowledge of every engineer who has worked in that centre. Certifications are maintained within the centre; upgrade cycles are absorbed by the centre; your platform roadmap is owned by engineers who have no other client.

BOT for Data & Analytics Centers of Excellence

A data platform BOT model builds the full-stack data and analytics team — ingestion through consumption through governance through AI/ML — in one location, under a coherent management structure, with a contractual path to client ownership. This data engineering center of excellence approach addresses a specific resourcing problem: a senior Databricks engineer or MLOps specialist in Germany or the UK commands a salary that many mid-market companies cannot sustain across a full team. The result is that data platforms are often resourced inadequately — one or two capable engineers maintaining infrastructure that requires five or six — with predictable consequences for reliability, governance, and delivery speed. For context on the Romanian talent market for data engineering roles, see the offshore development center in Romania page; for how data analytics functions fit within larger offshore operations, see the global capability center guide.

Data Sources and Ingestion (Transport Layer)

The foundation of any data platform is the pipeline layer that moves data from source systems into storage. Technologies at this layer include event streaming platforms (Apache Kafka, Apache Flink), managed cloud ingestion services (AWS Kinesis, Google Pub/Sub, Azure Event Hubs), and ELT connectors for batch movement (Fivetran, Airbyte). Change data capture tools such as Debezium enable near-real-time replication from operational databases.

Roles built in a BOT centre at this layer: Data Engineer, Streaming Engineer, Integration Architect.

Storage and Processing: Snowflake Offshore Team and Databricks Offshore Development

The processing and storage layer is where raw ingested data is transformed into structured, queryable assets. A Snowflake offshore team or Databricks offshore development centre built via BOT handles this layer — the dominant architectures today are the lakehouse pattern, combining the storage economics of a data lake with the query performance of a warehouse. Key technologies: Databricks (Delta Lake), Apache Spark, Snowflake, Google BigQuery, Amazon Redshift, Azure Synapse Analytics. Open table formats Apache Hudi and Apache Iceberg, and the transformation framework dbt (data build tool), are now standard components in mature data platforms.

Roles: Data Engineer, Analytics Engineer, Databricks/Spark Developer, Data Platform Architect.

Semantic and Consumption Layer

The consumption layer translates processed data into the metrics, dashboards, and self-service analytics that business users access. Technologies at this layer include semantic layer tools (dbt semantic layer, Cube.dev, AtScale), BI platforms (Looker with LookML, Power BI, Tableau, ThoughtSpot), and open-source alternatives (Apache Superset).

Roles: Analytics Engineer, BI Developer, Data Analyst, LookML Developer, Power BI Developer.

Data Governance and Quality

Data governance is the function that most organisations understaff relative to its operational importance. Without governed metadata, data lineage, and quality monitoring, the data platform becomes an unreliable asset. Technologies: Apache Atlas (open-source metadata), Collibra and Alation (enterprise data catalogues), Great Expectations and Monte Carlo (data quality and observability), dbt tests.

Roles: Data Governance Analyst, Data Quality Engineer, Data Catalogue Administrator.

AI and ML Platform

The ML platform layer — the infrastructure that enables model development, training, deployment, and monitoring — is the highest-cost and hardest-to-resource layer in the stack. Technologies: MLflow (experiment tracking), Kubeflow (ML pipeline orchestration), Amazon SageMaker, Google Vertex AI, Azure Machine Learning, Hugging Face model hub, Ray (distributed computing for ML).

Roles: ML Engineer, Data Scientist, MLOps Engineer.

Why BOT Is the Right Structure for a Data Centre of Excellence

Four factors make the BOT model particularly suited to data and analytics capability:

Scarcity and cost: D&A skills — particularly senior data engineers, MLOps engineers, and data architects — are expensive in Western markets and scarce. A BOT centre in Romania or Poland accesses a competitive market for these roles at materially lower salary cost, without sacrificing depth.

Strategic asset ownership: The data platform is increasingly a strategic asset — pipelines, data models, governance frameworks, and ML models represent years of accumulated intellectual work. A BOT centre with a Transfer clause means the client owns that asset outright, not the provider.

Full stack coherence: A BOT centre builds the ingestion, processing, governance, and consumption teams in one location, with proximity that enables the collaboration these layers require. Staff augmenting individual data engineers into different teams in different geographies produces the opposite — fragmented ownership of a system that requires end-to-end understanding.

Transfer value: At Transfer, the client does not just receive the team. They receive the data architecture, the pipeline code, the governance policies, the data catalogue, and the institutional knowledge of the data estate — accumulated over the Operate phase by engineers who have worked on nothing else.

Scaling the BOT Model

Growing the Team During Operate

Headcount growth during the Operate phase follows the same approval process as initial Build hiring: client defines the role, provider recruits, client approves the hire. Growth is priced at the same per-head commercial terms as the initial team.

Growth at pace above 30% per year typically strains the provider's recruitment capacity. Fast-scaling BOT engagements should negotiate dedicated recruitment resource within the provider's team, or agree a separate recruitment SLA for growth hiring.

Spinning Off a Second Team

Some clients use BOT to build a second team in the same delivery country (different domain or function) while the first team is still in the Operate phase. This is operationally clean if the second team has its own Team Lead and governance cadence — the provider's delivery manager can manage both, up to a point. Above two teams with a shared delivery manager, a dedicated country manager (provider-employed) becomes necessary.

From BOT to GCC

Large BOT engagements — 50+ people — often evolve into Global Capability Centers post-Transfer. The BOT model builds the foundation (people, process, infrastructure); the GCC model adds leadership, strategic function ownership, and long-term organisational identity. BOT is the fastest path to a functioning GCC without the full upfront captive cost.

Frequently Asked Questions