An Oracle project health check is an independent assessment of a live or stalled implementation. It examines enterprise structure, configuration quality, migration evidence, integration readiness, testing coverage and governance, then classifies every finding as blocker, must-fix or defer. The output is a decision: continue, reset scope, or change partner — supported by evidence rather than opinion.
A rescue is triage, not a restart. The first job is to establish what is genuinely broken versus what is merely late, because those need opposite responses.
What problem does this solve?
By the time a rescue is requested, the sponsor usually has two conflicting accounts: the partner reports progress against a plan, and the business reports that nothing works. Both can be true, and neither tells you what to do.
Migration is the most common real defect. Balances and open items were loaded without reconciliation evidence, so nobody can prove the opening position, and every subsequent close inherits the doubt.
Testing is the second. Where testing was done with sample data by project staff rather than real data by real approvers, defects surface after go-live at the worst possible time.
Governance failure compounds both: decisions were taken verbally, requirements were never numbered, and there is no traceable record of what was agreed versus what was built.
How the solution works
We assess against evidence, not status reports. Configuration is inspected in the system, migration is tested by re-reconciling a sample, and testing coverage is judged by what was actually executed rather than what was planned.
Findings are classified as blocker, must-fix or defer, with effort attached, so the sponsor can make a scope and sequence decision rather than receiving an undifferentiated defect list.
- 1Collect the plan, scope, requirement list, migration documentation and defect log — and record what does not exist.
- 2Review enterprise structure and module setup in the system against the stated requirements.
- 3Re-reconcile a sample of migrated balances and open items back to source to establish whether the position is provable.
- 4Determine what was tested, with what data, by whom — and which critical processes were never exercised.
- 5Check each interface for error handling, reprocessing and whether failures are visible.
- 6Produce blocker, must-fix and defer findings with effort, and a staged remediation plan with a rollback position.
Key capabilities
Independent health check
Evidence-based assessment of a live or stalled implementation with classified findings.
availableMigration verification
Re-reconciliation of migrated balances and open items against source records.
availableConfiguration review
Enterprise structure and module setup assessed against stated requirements.
availableIntegration assessment
Interface review covering error handling, monitoring and reprocessing.
availableRemediation delivery
Staged remediation against the classified findings, with acceptance criteria per item.
availableInstance and knowledge recovery
Recovering ownership of environments, credentials, backups and custom code source.
availableIndustry use cases
Stalled go-live
A date that has moved repeatedly with no agreed definition of what would make the system ready.
Unstable post-go-live
Live but not trusted: reconciliation differences, failed interfaces and manual workarounds.
Partner dispute
Sponsor and partner disagree on status, and an independent evidence-based view is needed.
Partner disengagement
The implementer has withdrawn or gone quiet, leaving incomplete documentation and unclear ownership.
UAE & GCC considerations
Rescues in the UAE frequently involve entities with statutory reporting deadlines that cannot move, which constrains the remediation sequence more than the technical findings do. VAT and corporate tax configuration is a common finding, because it was implemented once and never validated against real transactions. Where the original partner was appointed through a procurement process, the commercial position affects options — replacing a partner mid-contract has procedural consequences that should be understood before the technical decision is taken. For groups spanning UAE and Saudi Arabia, check whether one design was forced across both jurisdictions, which is a frequent root cause of reconciliation problems.
Implementation approach
- 1Health check (2-4 weeks) Independent assessment producing classified findings with effort estimates.
- 2Decision point Sponsor decides: continue, reset scope, or change partner — informed by evidence.
- 3Stabilise Fix blockers first, prioritising anything that prevents a defensible close.
- 4Rebuild evidence Re-run and document migration reconciliation so the opening position can be proved.
- 5Close the gaps Work must-fix findings with acceptance criteria and real-data testing.
- 6Transition to support Hand over to a managed support arrangement with documentation and a regression pack.
Security & deployment
A rescue often involves taking custody of environments and credentials that were controlled by a third party, so the first security action is usually an access review: who currently holds administrator access, whether any of it is shared, and which accounts belong to people no longer on the project. Custom code source and backups should be recovered and verified as part of the engagement, because assuming they exist is a common and expensive mistake. Where production data has been used in test environments without masking — frequent in troubled projects — that exposure should be recorded and remediated rather than quietly continued.
Limitations & prerequisites
- A health check reports what the evidence shows. Where documentation was never produced, part of the finding is that a decision cannot be verified — which is itself material.
- Rescue cannot reconstruct a reconciliation that was never performed. Some remediation is genuine reconstruction requiring finance effort from your side.
- Heavy undocumented customisation may need removal rather than repair, which changes user workflows and requires business agreement.
- Commercial and contractual constraints often limit the options more than the technical findings do, particularly where procurement rules apply.
- An independent assessment can strain the relationship with the incumbent partner; that consequence should be anticipated rather than discovered.
Continue, reset, or change partner
The health check exists to make this decision on evidence. These are the signals that usually point to each option.
| Signal | Continue | Reset scope | Change partner |
|---|---|---|---|
| Configuration quality | Sound, traceable to requirements | Sound but over-scoped | Poor or untraceable |
| Migration evidence | Reconciled and documented | Partially evidenced | Absent or unreproducible |
| Testing | Real data, real approvers | Planned but incomplete | Sample data only |
| Partner engagement | Responsive, transparent | Responsive, over-committed | Unresponsive or defensive |
| Typical outcome | Fix defects and proceed | Cut scope, re-plan dates | Recover instance, rebuild plan |
FAQ
Triage before action. Establish what is genuinely broken versus merely late, classify findings as blocker, must-fix or defer, then remediate in sequence with a rollback position. Restarting the project is almost never the right first move — it discards work that is sound along with the work that is not.
Enterprise structure and configuration review, migration reconciliation testing on a sample, testing coverage assessment, integration readiness, governance and documentation review, and a classified findings list with effort estimates and a staged remediation plan.
When the go-live date has moved more than once without an agreed definition of readiness, when the business and the partner give conflicting status, or when you cannot get a straight answer on whether migrated balances reconcile. Waiting until after go-live makes every option more expensive.
Yes, and often that is the better outcome. The health check produces evidence, not blame. Many engagements end with the incumbent continuing against a corrected plan and a clearer definition of done.
Typically two to four weeks depending on scope and how much documentation exists. Where documentation is thin, more time goes into inspecting the system directly, because the system is then the only reliable record.
The first priority is recovering ownership: environments, administrator credentials, backups and custom code source. Until those are secured, remediation planning is premature — you cannot commit to fixing a system you do not fully control.
Tell us the module, the release and the exact symptom.
Send the module in scope, your Fusion release or EBS version, and the exact error text or symptom with a screenshot where you have one. We reply with a written assessment: the likely cause, what we would check first, and whether it is a configuration fix, a data fix, or a defect that needs an Oracle service request. When Swedish Technology can help, we scope the remediation with effort and sequence before you commit to anything.
Request an Oracle AssessmentSources & evidence
- Oracle Help Center — Cloud Applications documentation — module setup, subledger accounting and period-close reference
- Oracle Help Center — all product documentation — database, middleware and infrastructure reference used for error diagnosis
- My Oracle Support — patches, known-issue notes and service requests; Oracle account required
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.