There are four credible delivery models for Oracle programmes. Most clients pick the wrong one for the wrong reasons. The usual wrong reasons are a headline cost comparison, habit, or a preference carried over from the last programme. The better reason is the shape of the work: how much of it depends on judgement and live stakeholder contact, and how much can be specified, built and tested against a clear definition.
The four models
- Onsite — leadership and high-judgement work at client site
- Offshore — configuration, build, integration in a low-cost centre
- Blended — onsite leadership + offshore build, the modal default
- Full-offshore — cost-optimised programmes with limited onsite touch
In practice, onsite and onshore are often used interchangeably. Both mean consultants working in or close to the client's time zone, whether physically at the client site or remotely from the same region. Offshore means a delivery centre in a different region, usually with a largely separate working day. Blended combines the two within one team and one plan. Full-offshore moves almost everything to the delivery centre and keeps only a thin onsite or onshore touchpoint.
How to choose an Oracle delivery model
The right Oracle delivery model is the one that matches the judgement density of the work to the location of the people doing it. Work that depends on business judgement, stakeholder negotiation and live decision-making, such as solution design, process workshops, data ownership decisions, cutover leadership and change management, belongs close to the business, onsite or onshore. Work that can be specified, built and verified against a clear definition, such as configuration, extensions, integration build, data conversion programs and regression test automation, can be delivered efficiently from an offshore centre.
Most Oracle Cloud and E-Business Suite programmes contain both kinds of work, which is why a blended model, with onsite leadership and offshore build, is the common default. A fully onsite model makes sense when almost every task is judgement-heavy; full-offshore suits stable, well-documented scope with little need for onsite presence. Whichever model you choose, govern it as a delivery model, not as a staffing arrangement.
When each one wins
Onsite wins when…
…the work is judgement-heavy, the stakeholders are co-located, and the time zone overlap with offshore is painful. Typical examples are the design phase of a Fusion implementation, where process owners need to be in the room to agree on standard processes, and the weeks around cutover and go-live, when decisions have to be made in hours rather than overnight. Onsite presence also matters when the programme depends on a small number of senior stakeholders whose time is scarce: the consultant adapts to their calendar, not the other way round.
Offshore wins when…
…the work is build-heavy, well-specified, and predictable. Configuration, extensions, integration build, regression test scripting. The prerequisite is a specification good enough that someone who was not in the design workshop can build from it and a tester can verify it. When that exists, an offshore team can run build and test in parallel with onshore design, and the time zone difference can work in the programme's favour: work handed over at the end of the onshore day can be built, unit tested and returned by the next morning.
Blended wins when…
…you want both — leadership presence onsite and cost-effective build offshore. This is what most successful programmes pick. A blended team usually keeps the programme manager, solution architect, functional leads and change lead close to the business, while the offshore centre carries configuration, technical build, integration, conversion and testing. The model works when both halves share one plan, one backlog, one defect process and one definition of done, rather than operating as two suppliers with a handover between them.
Full-offshore wins when…
…the scope is stable, processes are already documented, and the client has an experienced internal team that can own requirements and acceptance. Support and enhancement work on a live Oracle estate, regression testing for quarterly updates and well-bounded rollouts of an established template often fit this pattern.
Comparing the models
The table below summarises how the three main options differ. Full-offshore behaves like the offshore column with an even thinner onshore layer, so it inherits the same risks in a stronger form.
| Onshore | Offshore | Blended | |
|---|---|---|---|
| Best for | Solution design, stakeholder-heavy decisions, cutover and go-live leadership | Configuration, extensions, integration build, data conversion and test automation against clear specifications | Full-lifecycle implementations and upgrades that mix design judgement with substantial build |
| Collaboration and time zones | Full overlap with the business; decisions can be made in the same meeting | Limited overlap; relies on written specifications, structured handovers and scheduled overlap windows | Onshore leads bridge the gap; overlap windows for daily coordination, with build and test running across time zones |
| Cost profile | Highest cost per unit of effort; best reserved for work that needs presence | Lowest cost per unit of effort; real savings depend on specification quality and rework control | Balanced; concentrates higher-cost effort where judgement is needed and moves the rest offshore |
| Typical roles | Programme manager, solution architect, functional leads, change and training lead | Configurators, technical and integration developers, data conversion specialists, testers | Onshore leadership and functional leads paired with an offshore build, integration, conversion and test team |
| Risks to manage | Cost overruns, slower build throughput, dependence on a few individuals | Misread requirements, late escalation, hidden rework, weak knowledge transfer | Handover gaps between locations, duplicated effort, unclear ownership of decisions |
The right mix changes by phase
The mix should not be fixed for the life of a programme. Oracle's guidance on ERP implementation planning describes a sequence that runs from building the team and defining scope, through process mapping, data migration, integration, testing and training, to preparing for what comes after go-live. Each stage has a different judgement density, so the balance between onsite and offshore should shift with it.
- Discovery and design: weighted onsite or onshore. Process workshops, fit-to-standard decisions and the design authority need business owners in the room.
- Build and test: weighted offshore. Configuration, integrations, conversion programs and test scripts are built against signed-off designs, with onshore leads resolving questions in the overlap window.
- Cutover and go-live: weighted onsite again. Cutover rehearsals, go/no-go decisions and the first period-end need people who can make and enforce decisions in real time.
- Hypercare and support: moves back toward a blended or offshore-led model once the system is stable, with a named onshore owner for escalations.
Cloud programmes add a recurring dimension. Oracle applies mandatory quarterly updates to Fusion Cloud Applications, and its documentation describes non-production environments receiving updates about two weeks before production environments. Oracle also recommends testing that business processes run properly and communicating changes to users as updates are deployed. Regression testing of this kind is repeatable, well-specified work, which makes it a natural fit for an offshore or blended team working from a maintained test pack.
Governance makes or breaks offshore and blended delivery
Offshore delivery is not a way to buy cheaper hours; it is a delivery model with its own governance. The programmes that get value from it tend to share a small set of practices.
- A single integrated plan and backlog, owned by one programme manager, rather than separate onshore and offshore plans.
- Specifications written to be built from: process flows, configuration decisions, data mappings and acceptance criteria that a developer outside the workshop can follow.
- A defined daily overlap window, with a named onshore counterpart for each offshore workstream lead.
- Shared quality gates: code review, unit test evidence and functional sign-off applied the same way in both locations.
- Planned knowledge transfer, so that offshore leads understand the business context and onshore leads understand the build.
- Reporting on rework, defect leakage and blocked items, not only on hours and tasks completed.
Oracle's implementation planning guidance makes a related point from the client side: key leadership roles should not be treated as a side job to someone's existing duties, and the team needs people with project management, data migration, integration and change management skills drawn from across the business. A partner's delivery model, whatever its location mix, has to plug into that client team rather than replace it.
Common mistakes
- Picking offshore for cost without considering judgement-density of the work
- Picking onsite by default and missing substantial cost savings on work that could be built offshore
- Treating offshore as 'cheap labour' instead of a delivery model with its own governance
- Keeping the same mix from design through hypercare instead of adjusting it by phase
- Isolating the offshore team from business context, so that questions queue up instead of being answered in the overlap window
How ETHX Softcon structures delivery
Our teams work across a US presence and an offshore delivery centre in Pune, India, with an ETHXSoftcon Japan team for clients who need Japan-based coordination. Drawing on our leadership's more than 15 years of Oracle delivery and a network of over 120 certified consultants, we usually start from a blended model and adjust the mix by phase and workstream rather than fixing it at contract signature.
For common roles, consultants can typically be shortlisted within 48 hours and deployed in 5 to 10 business days, which makes it practical to add onsite capacity for cutover or offshore capacity for build and test when the plan calls for it. After go-live, hypercare typically runs for 4 to 8 weeks before the steady-state support model takes over.