Buyer guide
Microsoft Dynamics 365 staff augmentation vs project outsourcing
Short answer
Choose staff augmentation when your own lead can direct the Microsoft Dynamics 365 work and only needs more people. Choose a dedicated team when several roles need to work together for months under one named lead. Choose an outsourced work package when the result can be written down and you want the provider to answer for it. This guide from MS Dynamics Guys compares the three models by responsibility, fit and cost drivers, with a decision worksheet you can fill in.
Three models and the question that separates them
Every Microsoft Dynamics 365 engagement needs people who set priorities, settle design questions and accept finished work. The three models differ in who does those jobs. Answer that question first, and the model usually follows.
- Staff augmentation. Specialists join your team, and your lead directs their work.
- Dedicated team. Several roles work as one unit under one named lead, from your side or the provider's.
- Outsourced work package. The provider directs the work inside a written scope until you accept the result.
Project delivery, or project outsourcing, is the third model at a larger size. A whole implementation also has a written scope, change control and acceptance.
For a whole new system, see our Microsoft Dynamics 365 implementation services.
Location, such as nearshore or offshore, and partner subcontracting are separate choices. Each one works with any of the three models, as the term table below shows.
Responsibility matrix: who owns what in each model
Read across a row to see where one responsibility sits in each model. Agreements differ, so treat the table as a starting point for your contract, not as a promise from any provider.
| Responsibility | Staff augmentation | Dedicated team | Outsourced work package |
|---|---|---|---|
| What the provider answers for | Each person it supplies: skills, conduct and availability | The team's agreed capacity and continuity; in a supplier-led team, also the daily planning | A defined result, accepted against written criteria |
| What your side must supply | A lead with time every week and a release approver, plus a reviewer unless the provider supplies one | A product owner who ranks the work for each release, plus the team lead if the team is client-led | An approver, test data, answers at agreed checkpoints and acceptance testing |
| What gets built, and in what order | You decide, item by item, and you can reorder at any time | You decide through the roadmap and its priorities | You decide once, in the written scope; later changes go through change requests |
| Who assigns tasks each day | Your lead, in your backlog and stand-ups | The team lead named in the contract: yours if the team is client-led, the provider's if it is supplier-led | The provider's delivery lead |
| Code and configuration review | Named in the agreement: your reviewer, or a second engineer from the provider | Client-led: reviewers you name. Supplier-led: inside the team, under rules you approve | The provider; you check the evidence at acceptance |
| Acceptance of finished work | Your lead, item by item, with user acceptance testing (UAT) by your users | Your product owner, against criteria agreed for each release | Your approver, against the written acceptance criteria |
| Release to production | You approve each release | You approve, usually on the team lead's advice | You approve; the provider prepares the release as agreed |
| A person leaves or is absent | The provider runs the replacement process in the agreement; your team keeps the context | The provider keeps the agreed capacity staffed and briefs each new member | The provider staffs the work as the scope requires |
| Code, documents and access at the end | Code and solution files are in your repository from the first commit; you remove accounts on the last day | The same, plus a planned handover each time the team gets smaller | The deliverables and handover listed in the contract, accepted by you |
A dedicated team is client-led when your lead directs it, and supplier-led when the provider's lead does. Ask which one a proposal describes.
Two boundaries are easy to blur. Several augmented specialists are not a dedicated team until one lead plans their work together and the provider answers for the team's capacity. A supplier-led team is not an outsourced package either. You still pay for capacity and accept each release, but the provider does not answer for a defined result.
No model removes the work your business must do. Microsoft's guidance on project teams recommends a lead subject matter expert from the business for each workstream. That person stays on your side in every model, so plan their time before you compare offers.
What outstaffing, dedicated and managed mean in a proposal
Providers use different words for the same arrangement, and the same word for different ones. Map each term in a proposal to the model it describes, then check the details.
| Term in a proposal | What it usually means | Model in this guide | What to check |
|---|---|---|---|
| Outstaffing, team extension, resource augmentation | The provider holds the specialist's contract and pays them, and your team directs the daily work | Staff augmentation | Line management, leave and replacement stay with the provider; task direction stays with you |
| Dedicated developer | One person who works only on your tasks for the agreed hours | Staff augmentation, for the hours agreed in writing | The allocation in writing, and whether the person also works for other clients |
| Dedicated team | Several roles kept together on your work, with a named lead | Dedicated team | Whose lead it is, and how the team grows or shrinks |
| Managed team, managed service | The provider's lead plans the work against your priorities, often for a live system | A supplier-led dedicated team, or a support service | What the provider answers for: tasks, outcomes or agreed service levels |
| Outsourcing, work package, fixed-scope project | The provider owns an agreed result up to its acceptance | Outsourced work package | The acceptance criteria, the change process and the handover deliverables |
| Time and materials, fixed price | Ways to price the work, not models | Any model; a fixed price needs a fixed scope | Who pays when the work takes longer than planned |
| Nearshore, offshore | Where the people work compared with your location | Any model | The country, the time zone and the hours that overlap with yours |
| Subcontracting, white-label | A Microsoft partner buys capacity for its own client project | Any model, with the partner between the provider and its client (capacity for Microsoft partners) | Who holds the client relationship and what the client is told |
Labels alone do not tell you the model. For example, a fixed price without acceptance criteria leaves open what counts as done. Ask every provider the same questions:
- Who directs the work each day, and who accepts it?
- What do you answer for: each person's skills, the team's capacity or a result?
- How are changes priced and approved?
- What happens when a person leaves, and how is their knowledge written down?
- Where does the code live from the first commit, and who owns it under the contract?
All three models give outside people access to your systems. The security risk depends on how accounts are issued, limited and removed, not on the model. Ask for rates, minimum term, notice, the replacement process and working-hour overlap in writing for each engagement. Vague answers show you where the risk will land.
What drives cost in each model
This guide gives no rates or price ranges. Rates depend on the role, the product, the seniority, the allocation and the length of the engagement. The model changes something else: what you pay for, who carries which risk and which costs land on your side.
| Cost driver | Staff augmentation | Dedicated team | Outsourced work package |
|---|---|---|---|
| What you pay for | The time of named people | The capacity of a team, including the lead role | A defined result, at a fixed price from stated assumptions or by time against an estimate |
| Direction and management | Your lead's time, which no invoice shows | In the price when the lead is the provider's; your lead's time when the lead is yours | In the price, together with the provider's planning and reporting |
| Work that takes longer than planned | You pay for the extra time | The cost stays the same, but less of the roadmap fits, or you add people | At a fixed price, the provider absorbs it inside the scope, and the price carries a risk allowance. Priced by time, you pay for it |
| Changes of priority | No change request: you reorder the backlog inside the paid time | Little extra cost inside the capacity, but replanning takes the lead's time | Each change is a change request with its own price and date effect |
| Waiting for your decisions, data or access | Paid idle time | Paid idle capacity across the whole team | Delays, or change requests for late inputs |
| Onboarding and handover | Repeated for each new person; knowledge transfer happens as the work goes on | Once for the team, plus a planned handover when it shrinks | Concentrated at the end, so price it as a deliverable |
| Review and testing | Your reviewers' and testers' time, or a second engineer you pay for | Shared, as the contract states | In the price, though your users still test at acceptance |
Each model has a hidden cost. Staff augmentation needs direction: even a capable developer needs someone who decides trade-offs, answers process questions and reviews code. An outsourced work package needs definition. A vague scope returns as a risk allowance in a fixed price, as extra paid time in a time-based package, or as change requests later. A dedicated team needs a roadmap: without one, a stable team spends paid time waiting.
Some costs stay on your side in every model:
- Your people's time: the lead or product owner, the reviewers, the process owners who answer questions and the users who test.
- Licenses for outside people who sign in to your apps. A guest in customer engagement apps, such as Microsoft Dynamics 365 Sales, needs a license from your tenant and a security role. In Microsoft Dynamics 365 Business Central online, a partner's delegated administrators need no license in your tenant. They cannot run scheduled tasks in the job queue, though. Ask each provider which accounts and licenses its people need, and count them in your license plan.
- Onboarding and exit: accounts, environments and a walkthrough for each new person, then the handover and the removal of access at the end.
The pricing basis is a separate choice from the model. Staff augmentation and dedicated teams are usually priced by time or capacity. An outsourced package can have a fixed price once discovery has reviewed its inputs, or run on time against an estimate while unknowns remain. Neither basis is cheaper by default. Time-based work costs more when nobody directs it. A fixed price costs more when the scope keeps moving. Location changes both the rate and the cost of coordination. Compare offers by the total cost of the same scope, not by the hourly rate.
To budget a whole implementation, with licenses and delivery work on separate lines, use the Microsoft Dynamics 365 implementation cost guide.
Fit criteria and decision worksheet: which model fits your situation?
Each row is a fit criterion. Copy the table into your planning document and fill it in with the person who would direct the work. In each row, mark the one cell that is closest to your situation. Then count the marks in each column.
| Question | Points to staff augmentation | Points to a dedicated team | Points to an outsourced work package |
|---|---|---|---|
| 1. Who will set priorities and accept the work? | A named lead on our side, with time for it every week | Our product owner sets priorities, and a team lead runs the daily work | We can write the acceptance criteria now and accept at agreed points |
| 2. Who can review code and configuration for this product? | Someone on our team | The team lead, under review rules we approve | Nobody yet, so the provider must review and show evidence |
| 3. How settled is the work? | Many small items that change week to week | A roadmap for months, with details that change | One result that we can describe in writing now |
| 4. Can the work be separated from the rest of the system? | No, it touches many parts of the system every week | Partly: the team can own one area, such as service or finance | Yes, it has clear edges, such as one integration |
| 5. How many roles does the work need? | One or two | Three or more that depend on each other | We want the provider to decide the roles |
| 6. How long will the need last? | Until a backlog is cleared, or open-ended for one role | Many months, with more work expected after that | Until one result is accepted |
| 7. How much time can our lead give each week? | Time to direct and check work every day | Time for priorities and regular reviews | Time for decisions, testing and acceptance at set points |
| 8. Who should carry the risk that work takes longer? | We do, so that we can change priorities freely | We do, as less scope for the same cost, while the provider keeps the capacity staffed | The provider, for the agreed scope, at a fixed price after discovery |
| 9. Where must product knowledge end up? | Inside our team, as the work happens | Inside the team, with a handover if it gets smaller | In documents and a walkthrough at handover |
A clear majority in one column suggests that model. A split usually means a combination, for example a work package for one defined result and staff augmentation for the rest of the backlog.
Some answers rule a model out, whatever the count says:
- Nobody on your side can direct the work day to day. Rule out staff augmentation and a client-led dedicated team. A supplier-led team or a work package can still fit, if someone on your side sets priorities and accepts results.
- Nobody on your side can set priorities or accept results. No model works yet, because no model moves those decisions to the provider. Name a product owner or an approver first.
- Nobody on your side can review the code or configuration. Choose staff augmentation only if the agreement names a reviewer from the provider. Otherwise unreviewed changes reach production, and the new person becomes the only one who understands them.
- Only one skill is missing, and your lead has time to direct it. Rule out a dedicated team. It adds a lead role and team planning that one person does not need.
- Nobody owns a roadmap for the next releases. Rule out a dedicated team for now. Its fixed capacity would wait for direction while you pay for it.
- You cannot describe the result yet. Rule out an outsourced work package for now. Buy discovery first, as a consulting engagement or a separately priced first phase. Then fill in the worksheet again.
Switching models, and the evidence each switch needs
Engagements often change model over time. Knowledge gets lost at the switch, so agree the evidence for each switch before it happens.
| Change | When it makes sense | Evidence to collect first |
|---|---|---|
| Work package, then staff augmentation | The result is live, and smaller changes keep coming | Architecture notes, release steps, open defects and a walkthrough for the people who stay |
| Staff augmentation, then a dedicated team | The backlog now needs several roles, and your lead cannot direct them all | A written split of decisions between your product owner and the team lead |
| Staff augmentation, then a work package | Part of the backlog has turned into one defined result, such as an integration | A scope baseline, acceptance criteria and the current code in your repository |
| Dedicated team, then a smaller team or your own staff | The roadmap slows down, or you have hired your own people | Code with full history in your repository, the team's decision log and a named next owner for each app, extension and integration |
| One provider, then another | The relationship ends, or the work moves in-house | All of the above, plus removed or reduced access for the old provider in every environment |
Before any switch, check three product details. They decide what you can take with you and how you close the old provider's access:
- Business Central extensions. A per-tenant extension is built only for your environments. Like every extension, it hides its source by default. If you own its code and agree to expose it, Microsoft recommends at least two settings: allow debugging, and include the source in symbol files. Your provider sets both in the extension's
app.jsonfile. Check them, and check that the source is in your own repository. - Business Central online administration. A partner that administers your environments works through granular delegated admin privileges (GDAP) that you accept. By default, every partner with that access can open every environment, so allow or block partners per environment. When a partner leaves, Microsoft lists clean-up steps. Remove its delegated admin privileges, disable its users in Business Central and remove its apps that you authorized to connect to Business Central. Then clear its settings in the Business Central administration center, such as notification recipients and the support contact. An environment keeps its partner access setting after the relationship ends. Change that setting too, or the partner can open the environment again if it regains access to your tenant.
- Customer engagement apps and other apps on Dataverse. Microsoft Dynamics 365 Sales and Customer Service run on Microsoft Dataverse. Microsoft's application lifecycle management (ALM) guidance treats source control as the source of truth. Each component belongs to the publisher of the solution where it was created. Once a managed solution ships the component, that publisher cannot change. Ask every provider to build in your solution, under your publisher, from the first day.
Which model will MS Dynamics Guys suggest for our work?
We start from your worksheet answers, or we fill in the worksheet with you in the first conversation. Questions 1 and 2 weigh most: who sets priorities and accepts the work, and who can review it for this product. We then name a model, or a mix of models, and explain the reason before any introduction or quote.
Your answers are enough for a suggestion. The work itself needs more from your side: named accounts in your tenant, someone who reviews or accepts each result and someone who approves releases.
If your lead can direct the work, we suggest specialists who join your team. Staff augmentation with MS Dynamics Guys describes the arrangement.
If the result can be written down, we suggest a scoped project. See Microsoft Dynamics 365 development services, or Microsoft Dynamics 365 implementation services for a whole new system.
If you need people but cannot name the role yet, start with the role chooser for Microsoft Dynamics 365 specialists.
Every engagement with MS Dynamics Guys follows one delivery model. Code and solution files sit in your repository from the first commit, and a written handover follows when work or people change. If your own team, a standard feature or another provider covers the work better, we say so instead of suggesting a model.
When MS Dynamics Guys fits
MS Dynamics Guys fits Microsoft Dynamics 365 owners who want a model suggested from their worksheet answers, with the reason, before any introduction or quote.
A good fit when
- You can fill in the worksheet with the person who would direct the work, even if the answers point to different models.
- You want code, solution files and documents in your repository from the first commit. A later change of model or provider is then a handover, not a rebuild.
Choose another route when
- Your worksheet rules out every model, for example because nobody on your side can set priorities or accept results. Name that person first. No provider, MS Dynamics Guys included, can take over those decisions.
- You want a permanent employee on your payroll. All three models in this guide are services between two companies.
Questions about choosing an engagement model
Which model carries the least risk?
None of them by default. Each model puts the risk in a different place:
- Staff augmentation. You carry the risk of overruns and of weak direction. The provider answers for each person's skills.
- Dedicated team. Your cost per period stays fixed, so an overrun costs you scope rather than extra money. A weak roadmap wastes paid time. The provider carries the risk of keeping the capacity staffed.
- Outsourced work package. At a fixed price, the provider carries the effort risk for the agreed scope. Priced by time against an estimate, you carry it. Either way, you carry the risk that the scope describes the wrong result.
Choose the model whose risk your team can manage most easily.
Who answers for a defect in production in each model?
It depends on who directed and accepted the work. With staff augmentation, your team directed and accepted it, so your lead decides the fix. The provider answers for the specialist's skills, not for the result. In a dedicated team, the team fixes the defect inside the capacity you pay for, so less new work fits that sprint. In an outsourced work package, the provider fixes delivered work that fails an agreed criterion before you accept it. In every model, agree in writing before work starts how defects found after acceptance are handled.
Is staff augmentation cheaper than an outsourced work package?
Not by default. A fixed package price includes the provider's management and an allowance for delivery risk. Staff augmentation moves both to you: management becomes your lead's time, and risk becomes overruns that you pay for. The cost table above shows where each cost lands, including your own team's time.
Can we combine models in one Microsoft Dynamics 365 program?
Yes, and many programs do. Give each piece of work one owner and one model, as your worksheet result suggests.
Three rules keep a combination safe. Keep all code and solution files in one repository. Release through one calendar that one person on your side approves. Do not let two teams change the same component without a shared review.
Do nearshore and offshore teams follow a different model?
No. Nearshore and offshore describe where people work. The model describes who directs them and who answers for the result, so any of the three can run from another country. Location changes the coordination: overlapping hours, handoffs between time zones and release approvals. Ask for the country, the time zone and the overlap in writing. Check how daylight-saving changes move the overlap during the year.
Not sure which model fits your work?
Tell us who would direct the work on your side, what needs doing and for how long. We reply with the model we would suggest and the reason, before any introduction or quote.
Product documentation referenced on this page
- Organize your Microsoft Dynamics 365 project team Microsoft Learn, checked October 4, 2026
- Invite users with Microsoft Entra B2B collaboration Microsoft Learn, checked October 4, 2026
- Create users (Power Platform admin) Microsoft Learn, checked October 4, 2026
- Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse Microsoft Learn, checked October 4, 2026
- Supported customizations for Microsoft Dataverse Microsoft Learn, checked October 4, 2026
- Business Central administration center Microsoft Learn, checked October 4, 2026
- Delegated admin access to Business Central online Microsoft Learn, checked October 4, 2026
- Administration of Business Central online Microsoft Learn, checked October 4, 2026
- Manage access to environments (Business Central) Microsoft Learn, checked October 4, 2026
- Programming in AL Microsoft Learn, checked October 4, 2026
- Extension types and scope (Business Central) Microsoft Learn, checked October 4, 2026
- Resource exposure policy setting Microsoft Learn, checked October 4, 2026
- FAQ for technical details (Shopify Connector) Microsoft Learn, checked October 4, 2026
- Solution concepts with Power Platform Microsoft Learn, checked October 4, 2026
- Application lifecycle management (ALM) with Microsoft Power Platform Microsoft Learn, checked October 4, 2026
- X++ language reference Microsoft Learn, checked October 4, 2026