How to Build an SAP Team: Which Delivery Model Fits? IT Recruitment vs SAP Staff Augmentation vs Managed Services
An S/4HANA programme needs six to ten SAP consultants for roughly a year, then one or two for the next decade. No single staffing model serves both halves of that curve well. Permanent recruitment builds the long-term team but cannot fill a twelve-month peak in time; staff augmentation fills the peak but leaves nothing behind when the contracts end; managed services take the run phase off your hands but at the cost of in-house SAP knowledge. Most companies that get this wrong do so by picking one model for the whole lifecycle rather than matching a model to each phase.
This article compares the five ways Itelence supplies SAP capability — permanent hires through IT recruitment and staffing in Poland, SAP staff augmentation, an extended project team, managed application services, and build-operate-transfer — against the four phases of an SAP lifecycle. The comparison is written for CIOs and SAP programme leads in the United States, the United Kingdom and the DACH region who are planning an S/4HANA migration or rebuilding an SAP team after one. It ends with a decision rule that has held up across Itelence engagements: recruit for roles that will still exist in 24 months, augment for everything else.
Key Insights
- Match the model to the lifecycle phase, not the programme — blueprint, build, go-live and application management need different headcounts, different seniority mixes and different levels of vendor responsibility. One model for all four phases overpays in at least two of them.
- Permanent recruitment wins for run-phase roles — the SAP basis lead, the finance functional owner and the integration architect who will hold the landscape for ten years belong on your payroll. They are also the hardest to hire, which is why recruitment should start before the build phase, not after go-live.
- Staff augmentation is a peak-shaving tool — it is the right answer for the twelve to eighteen months when a programme needs three times the SAP headcount it will keep afterwards, and the wrong answer for any role you want to own long term.
- Managed services trade knowledge for predictability — an AMS contract converts SAP support into a fixed monthly cost with an SLA, but every ticket resolved by the vendor is process knowledge that does not accumulate in-house.
- Build-operate-transfer only pays off above roughly 15 people — below that, the governance overhead of standing up a dedicated SAP centre outweighs the ownership benefit; above it, BOT is the only model that ends with a full team on your books.
- The hybrid is the default, not the exception — in Itelence SAP engagements the stable pattern is a small permanent core recruited early, augmented consultants for the migration window, and either in-house or managed support for the run phase, decided by whether SAP is a differentiator for the business.
- Vacancy cost dominates fee cost for SAP roles — a delayed functional lead pushes an entire workstream, so compare models per week the role stays open rather than per invoice.
What are the four phases of an SAP lifecycle, and why does each need a different team?
An SAP lifecycle has four phases with different staffing profiles: blueprint (2–4 months, small senior team), build and test (9–15 months, the headcount peak), go-live and hypercare (2–3 months, peak plus 24/7 coverage), and application management (open-ended, one to three people per landscape). The headcount ratio between the build peak and the run phase is typically three to five to one, and that ratio is the whole reason the staffing question is hard.
The deadline driving most of these programmes is public. SAP’s maintenance strategy for SAP Business Suite 7 ends mainstream maintenance for ECC 6.0 at the end of 2027, with optional extended maintenance available until the end of 2030 at a premium. Every company still on ECC is therefore planning a build phase that overlaps with everyone else’s, in a consultant market that does not grow on the same schedule.
The phases differ in more than headcount. Blueprint needs functional leads who can challenge business process owners and a solution architect who has seen at least two S/4HANA landscapes — seniority over volume. Build needs module consultants, ABAP and Fiori developers, integration and basis specialists, and testers, most of whom will not be needed after go-live. Application management needs people who know your configuration, your custom code and your interfaces, and who will still be there in year five. A model that is right for one of those profiles is usually wrong for another.
Which SAP delivery models are on the table?
Five models cover almost every way an SAP team gets staffed: permanent recruitment, staff augmentation, an extended project team, managed services, and build-operate-transfer. They differ on three axes — who employs the people, who manages the work, and who carries the risk of a wrong hire or a missed deadline. The table below sets the five against those axes; the sections that follow test each model against the lifecycle phases.
| Model | Who employs | Who manages the work | Time to first person | Commitment | Best-fit phase |
|---|---|---|---|---|---|
| Permanent recruitment | You | You | 6–12 weeks to start (offer, notice period) | Open-ended employment | Run phase; core roles across all phases |
| SAP staff augmentation | Provider | You | 1–3 weeks | Monthly, typically 3–12 months | Build, test, hypercare |
| Extended project team | Provider | Shared — provider PM inside your governance | 3–6 weeks for a formed team | Per phase or per workstream | Build of a bounded workstream (e.g. one module, one rollout) |
| Managed services (AMS) | Provider | Provider, against an SLA | 4–8 weeks including transition | 12–36 months, fixed monthly fee | Application management after go-live |
| Build-operate-transfer | Provider, then you | Provider, then you | 2–4 months to a working centre | 18–36 months to transfer | Long-term SAP centre of 15+ people |
Two of these comparisons already have their own articles on this blog — staff augmentation against recruitment and staff augmentation against managed services — and the SAP staff augmentation guide covers module-level matching and Polish consultant rates in depth. This article does not repeat that material; it puts the models side by side against the SAP lifecycle specifically.
When does permanent IT recruitment beat every other model for an SAP team?
Permanent recruitment is the right model for any SAP role that will exist in 24 months and that holds knowledge you cannot afford to lose — in practice the basis or platform lead, one functional owner per core process area (finance, logistics, HR), and the integration architect. These are the people who will know why a custom enhancement exists, which interface breaks under month-end load, and what was agreed with the business during blueprint. Renting that knowledge for a decade costs more than owning it, and losing it at contract end costs more still.
The case for recruitment is strongest when it starts early. A functional owner hired during blueprint sits through every design decision and enters the run phase already knowing the landscape; the same person hired after go-live inherits documentation of variable quality and a vendor who is about to leave. The main objection to recruitment is speed, and it is a fair one. SAP is a niche profile, and niche ICT vacancies are the ones companies report as hardest to fill — Eurostat’s statistics on hard-to-fill ICT vacancies record 57.5% of EU enterprises that recruited or tried to recruit ICT specialists in 2023 reporting difficulty filling the role. Starting the search six months before the role is needed is the only reliable mitigation.
From Itelence recruitment practice: a Polish IT search runs market mapping and active sourcing across days one to five, technical screening from day three, and delivers a first shortlist around day seven to ten — an average of seven days from brief to first shortlist. SAP searches are on the slower end of that range because module and release-version matching narrows the pool before the first interview, and German-speaking SAP consultants take longer to source than English-speaking developers on the same brief. The fee is a percentage of the placed candidate’s first-year gross salary, payable on successful placement.
Recruitment is the wrong model for the build peak. Hiring eight consultants permanently for a twelve-month migration leaves you with eight salaries and two roles once the programme closes; the alternatives are redundancies, which are expensive and slow in Germany and the UK, or underemployment, which is expensive everywhere.
When is SAP staff augmentation the better choice?
SAP staff augmentation is the better choice for the build, test and hypercare phases, when a programme needs three to five times its steady-state headcount for a period you can name in advance. Augmented consultants are employed by the provider, managed by your project lead, and released when the phase ends — which is exactly the shape of the demand.
“S/4HANA migration projects create a demand pattern that permanent hiring simply can’t serve. You need six to ten certified consultants for twelve months, then the requirement drops to one or two post-go-live. The companies that handle this well plan their augmentation alongside their SI engagement — using the SI for overall programme governance and filling specific module gaps with augmented specialists.”
— Szymon Stadnik, CEO, ITELENCEThe economics are the other argument. Senior S/4HANA architects and functional leads in the UK and DACH contractor markets command day rates of €600–1,100, and comparable profiles in the US bill at $800–1,400 per day; certified consultants supplied through nearshore development Poland engagements cost materially less for the same module certifications. For a four-consultant, twelve-month migration, that gap runs to hundreds of thousands of euros in direct consultant cost, before the effect of full working-day overlap with London, Frankfurt and Zurich is counted.
Where augmentation fails is the run phase. Consultants who have rolled off carry your process knowledge with them, and a landscape supported by a rotating cast of contractors accumulates undocumented configuration faster than any wiki can absorb. If augmentation extends past hypercare, it should be a deliberate bridge to a permanent hire or an AMS contract, with knowledge transfer written into the statement of work.
When should you choose an extended project team or managed services instead?
Choose an extended project team when a workstream has a clear boundary and you want the provider to own its delivery — a single-module implementation, a country rollout on an existing template, or a BTP integration layer — and choose managed services when SAP is not a differentiator for your business and the run phase is better bought as an SLA than staffed. Both models move management responsibility to the vendor; the difference is whether that responsibility is scoped to a project or to an ongoing service.
The two options resolve different problems, so it helps to look at them separately before deciding whether either belongs in your plan.
What does an extended project team give you that augmentation does not?
An extended project team gives you a delivery owner. In augmentation, your project lead assigns work to individual consultants; in an extended IT project team, the provider’s PM runs a workstream inside your programme governance and answers for its milestones. This is the right shape when your own SAP programme office is stretched across the core migration and cannot also run, say, the Ariba or SuccessFactors track. It is the wrong shape for the core migration itself, where you want the design decisions and the accountability in-house.
When does managed application services make sense for SAP?
Managed services make sense for SAP when the run phase is a cost to be controlled rather than a capability to be built. An IT managed services contract for SAP application management converts support into a fixed monthly fee with defined response and resolution times, and removes the recruitment problem for L1 and L2 entirely. The trade is knowledge: every incident the vendor resolves is process understanding that lives with the vendor. Companies where SAP finance and logistics are core to how they compete generally keep at least one functional owner per area in-house and buy L1/L2 support as a service; companies where SAP is back-office plumbing can outsource the whole run phase through SAP consulting and maintenance and spend the saved headcount elsewhere.
Planning an S/4HANA team and not sure which roles to hire versus rent?
Send us your programme timeline and module scope. Itelence maps each role to recruitment, augmentation or managed support and quotes both the fee and the time to first shortlist.
When does build-operate-transfer fit an SAP team?
Build-operate-transfer fits when you intend to run an SAP competence centre of 15 or more people for the long term and want to end up owning it, without setting up a Polish entity, payroll and office on day one. Under a build-operate-transfer model in Poland, the provider recruits the team, runs it under your processes for 18–36 months, and then transfers the people, the contracts and the infrastructure to your own legal entity. It is the only model on this list that ends with a full SAP team on your books rather than on a vendor’s.
Below about 15 people the model does not pay. The governance overhead — a separate management layer, a transfer plan, a legal entity to receive the team — is roughly fixed, and spreading it across six SAP consultants costs more than recruiting them directly or augmenting. Above that size, and especially for groups consolidating SAP support for several countries into one centre, BOT is what a Polish delivery hub looks like when it is planned to be permanent. The comparison of a nearshore development centre against BOT covers the transfer mechanics in detail.
How do the models compare on cost, risk and knowledge retention?
On cost per person, augmentation and managed services are cheapest during the build peak and recruitment is cheapest over a ten-year horizon; on risk, managed services carry the least delivery risk for you and recruitment the most; on knowledge retention, recruitment and BOT are the only models that leave capability inside the company. No model wins all three, which is why the choice has to be made per phase.
| Criterion | Recruitment | Staff augmentation | Extended project team | Managed services | BOT |
|---|---|---|---|---|---|
| Cost over 12-month peak | High — salaries continue after peak | Lowest | Low–medium | Medium — transition cost | High — setup cost |
| Cost over 10-year run | Lowest | Highest | Not applicable | Medium, predictable | Low after transfer |
| Wrong-hire risk carried by | You | Provider — replace within notice | Provider | Provider | Provider until transfer |
| Knowledge retained in-house | Full | Only what is transferred | Only what is transferred | Minimal | Full after transfer |
| Management effort for you | Full | Full | Shared | Minimal | Shared, then full |
| Exit cost | Redundancy (high in DE/UK) | Notice period | Per contract | Transition-out, 2–3 months | Transfer is the exit |
One line in that table is worth isolating. The recruitment fee itself is a small number in this context — SHRM’s 2025 Benchmarking Survey puts average internal cost per hire at $5,475 for non-executive roles in the US, and an agency fee for a senior SAP profile is a multiple of that, not an order of magnitude. For SAP roles, the cost that dominates is neither the fee nor the day rate but the cost of the role staying open. A missing finance functional lead during build stalls a workstream that a dozen other people are waiting on; measured that way, the fastest model to fill the role is usually the cheapest, whatever the invoice says. This is the same conclusion the agency-versus-direct-hire comparison reaches for developers, and it is stronger for SAP because the dependency chain is longer.
What does a phased SAP staffing plan look like in practice?
A phased plan assigns a model to each lifecycle phase and each role class, so that the permanent core is recruited before the build peak, the peak is augmented, and the run phase is decided by whether SAP is core to the business. The plan below is the pattern that has held up across Itelence SAP engagements for mid-size and enterprise clients in the UK, DACH and the US; the numbers are indicative for a single-instance S/4HANA migration with three to four core modules.
- Blueprint (months 1–4): recruit the solution architect and one functional owner per core area permanently — the search starts at programme approval, not at blueprint kick-off. Augment one or two senior module consultants to bring second-landscape experience into design.
- Build and test (months 4–16): augment the peak — module consultants, ABAP/Fiori developers, integration and test resources — through SAP staff augmentation, with knowledge-transfer deliverables written into each contract. Keep the permanent core in the design and sign-off seats.
- Go-live and hypercare (months 16–19): retain the augmented team at full strength through hypercare; start the transition to run-phase support in parallel, whether that is a permanent basis lead or an AMS onboarding.
- Application management (month 19 onward): if SAP is a differentiator, keep the functional owners in-house and buy L1/L2 as a managed service; if it is not, move the landscape to full managed services and redeploy the internal headcount. For groups planning a 15+ person SAP centre, this is where BOT starts.
From Itelence delivery experience: the most common correction we make to a client’s SAP staffing plan is timing, not model choice. Recruitment for the permanent core is typically started at build kick-off, when the functional owners are already needed in design workshops; moving that search back to programme approval — four to six months earlier — is the single change that most reduces dependence on augmented consultants during the run phase.
How does the choice differ for US, UK and DACH companies?
The lifecycle logic is the same in all three markets; what changes is the exit cost of a wrong model and the language requirement. German and UK employment law makes redundancy after a build peak slow and expensive, which pushes the peak firmly toward augmentation; US at-will employment lowers that cost, but US day rates for senior SAP profiles are the highest of the three markets, which pushes the same way for a different reason. DACH programmes add a language filter: German-speaking SAP consultants are a smaller pool and take longer to source, so recruitment lead times should be planned longer than for an English-language brief.
Time zone affects the run-phase decision more than the build. For UK and DACH companies, an SAP support team based in Poland works the same hours as the business, so in-house, augmented and managed models all deliver same-day resolution; the country-specific guides to staff augmentation for UK companies and IT nearshoring for DACH companies cover the contractual and language details. For US companies, a Polish team gives morning-to-early-afternoon overlap with the East Coast, which suits a follow-the-sun support model and month-end close coverage but needs to be designed in; the US staff augmentation guide sets out how that overlap is typically structured.
How do you decide which model to use for each SAP role?
Ask three questions per role: will this role exist in 24 months, does it hold knowledge the business cannot afford to lose, and does it need to start in under a month? Two yes answers to the first two questions mean recruit; a yes to the third with a no to the first means augment; a no to all three means the role is a candidate for managed services. Applied role by role, this produces the hybrid plan described above without anyone having to choose a single model for the programme.
The reason Poland is where those roles get filled, whichever model you pick, is the depth of the pool. According to the Polish Investment and Trade Agency’s 2025 IT Sector Report, Poland has approximately 600,000 programmers, more than 25% of the entire development community in Central and Eastern Europe, and the country’s long history as an SAP delivery market for German-speaking clients has built module-level depth that smaller nearshore markets do not have. Nearshoring in Poland gives a UK or DACH programme same-hours consultants and a US programme a lower-cost senior bench; nearshore IT services Poland providers such as Itelence supply all five models from the same talent pool, which is what makes a phased plan practical rather than theoretical. Whether the role ends up as a permanent hire, an augmented consultant or part of a managed service, the sourcing runs through the same IT nearshoring Poland capability, and nearshore software development Poland teams for the custom ABAP and integration work sit alongside the functional consultants rather than in a separate vendor.
Itelence is a Poland-based IT outsourcing and staff augmentation company that supplies SAP consultants, dedicated teams and managed support to clients in the DACH region, the Nordics, the UK, Benelux, France and the United States. Unlike a system integrator, it does not sell programme delivery; unlike a recruitment agency, it can supply the same profile as a permanent hire, an augmented consultant or part of a managed team — which is the practical precondition for staffing an SAP lifecycle phase by phase.
Get a phase-by-phase SAP staffing plan for your programme
Share your S/4HANA timeline and module scope. Itelence maps every role to recruitment, augmentation or managed support, with lead times and costs for each.
Frequently Asked Questions
Common questions from CIOs and SAP programme leads choosing between recruitment, augmentation and managed services.