Tiered application support
Three tiers across JD Edwards and Oracle Cloud, from business hours to 24×7×365, staffed by people who have implemented your stack.
Run the system
Cloud & Managed Services
Support that starts where the project ends.
Tiered application support and cloud operations — with the response targets, coverage hours, and exclusions published on this page rather than held back for the proposal.
Overview
The riskiest moment for an ERP is not go-live — it is the quiet years after, when knowledge walks out the door and small workarounds compound into a system nobody fully understands.
Our managed-services team runs the environment as an extension of yours: same people, documented decisions, a stated service level, and a payback model you can defend to the board.
Where it fits
Industrial ManufacturingOil & GasEPC
Delivery in the field
What we do
Inside Cloud & MS
Cloud migration
On-prem to cloud moves sequenced to minimize downtime and re-work.
Payroll & back-office support
Running the pay cycle and the month-end close with you — scoped by deadline rather than by ticket, for teams where one person currently knows how it works.
Optimization reviews
Regular reviews that retire workarounds and keep the configuration aligned to the business.
How it runs
Plan — Build — Run
01
Plan
Assess the current environment, licensing, and support gaps; model the true cost and payback of each move.
02
Build
Migrate and harden environments with rehearsed cutovers and documented runbooks.
03
Run
Operate the platform against published response and availability targets, with optimization reviews that keep it aligned to the business.
What we support
Tier 2 and Tier 3 cover, on the systems that are still running your business
Two different things get called a tier in this market. One is what you buy. The other is how deep the person answering your ticket can go — and that is the one that decides whether an incident closes today.
Tier 1
Not what you are buying from us
Password resets, ticket logging, and routing. Most organizations already have this, and the ones that outsource it rarely need a consultancy to do it.
Tier 2
Functional and technical consultants
Training, report development, troubleshooting, configuration, and the requests that need somebody who knows how your modules were set up rather than somebody reading a script.
Tier 3
Senior specialists and the people who built it
Mission-critical application support: root cause on the incidents nobody else can close, integration and batch failures, performance work, and the escalations that end at a partner.
JD Edwards EnterpriseOne
Full application management across financials, distribution, manufacturing, and project costing — on-premise, hosted, or on cloud infrastructure.
- Tools release upgrades and ESU application, regression tested first
- UDO, orchestration, and custom object management
- Interface and batch monitoring, with the UBE schedule owned end to end
- Report development and BI Publisher work as service requests
JD Edwards World
Still running the business at plenty of operations, and increasingly hard to staff for. We keep World estates supported for as long as you want to run them — including through a move off, if that is where you land.
- Green-screen functional and technical support from people who have done it
- World-to-EnterpriseOne assessment when you want the option costed
- Report and world writer development
- Support for the environment while a replacement program runs alongside it
Hubble
Reporting, analytics, and planning on top of JD Edwards. Supported as part of the same service rather than bounced to a separate vendor when a number looks wrong.
- Report and dashboard development against live JD Edwards data
- Analytics model maintenance as the underlying configuration changes
- Planning and budgeting cycle support through the calendar
- Upgrade and patch management for the Hubble estate
Oracle Cloud
Planning, close, and reporting applications kept current through Oracle’s monthly update cadence.
- Monthly update regression testing ahead of the window
- Business rule, form, and metadata change management
- Close calendar and consolidation support through period end
- Dashboard and report development as service requests
And the cycles themselves, where you would rather not carry them alone
Payroll and the month-end close run to a calendar, not to a ticket queue. These are scoped by deadline and cycle rather than by response target, and they run alongside the platform support above or on their own.
Payroll operations support
Running the pay cycle with you, not just supporting the payroll module. For teams carrying multi-state, union, or prevailing-wage payroll with one or two people who know how it works — and no cover when they are away.
- Pay-cycle support through each run, including the pre-run audit and gross-to-net review
- Time, labor-distribution, and general-ledger interface monitoring, with breaks worked before payroll closes
- Union, prevailing-wage, and certified-payroll reporting produced on the statutory calendar
- Quarter-end and year-end tax filing, W-2 and W-2c support, and carrier and 401(k) reconciliations
- Payroll tax table, rate, and benefit-plan updates applied and regression tested ahead of the effective date
- Named payroll lead with a documented backup, because a single point of failure is the problem you are solving
Back office & shared services support
Transaction and close support across finance and shared services — accounts payable, receivable, and the month-end close — for operations where volume arrives faster than headcount does.
- Accounts payable and receivable transaction support, including exception and three-way-match queues
- Month-end close task support against your close calendar, with status reported daily through close week
- Reconciliation preparation and evidence collection, handed over audit-ready rather than half-finished
- Master-data maintenance for supplier, customer, and employee records under an agreed control
- Automation and bot monitoring, with failed runs reworked manually so the period still closes on time
- Continuous cover through close week on a rota agreed a quarter in advance
Support tiers
Three levels of cover, with the difference written down
Most environments do not need round-the-clock cover, and paying for it is how a support contract quietly becomes indefensible. Start at the tier your operation actually needs — we review the fit every quarter and will move you down if the ticket record says you are over-covered.
Foundation
Tier 1A single production environment past hypercare, with an internal team that still handles day-to-day requests.
- Coverage
- Mon–Fri, 08:00–18:00 Central
- P1 response target
- 1 hour
- A named service lead and a two-person delivery pod who stay on your account
- Incident and service-request handling within coverage hours
- Quarterly Oracle update regression testing before it reaches production
- Environment refresh and clone schedule managed for you
- Monthly service review against the ticket record
Not included — Overnight and weekend cover. Outside coverage hours you reach an on-call escalation queue, not an engineer at a keyboard.
Operate
Tier 2Multi-entity operations where a failure during close week has a reporting deadline attached to it.
- Coverage
- Mon–Sat, 06:00–22:00 Central, plus continuous cover through close week
- P1 response target
- 30 minutes
- Everything in Foundation, with a three-person pod and a named backup lead
- Continuous close-week cover on a rota agreed a quarter in advance
- Integration and batch-job monitoring with alerts routed to a shared channel
- An agreed monthly pool of enhancement hours, tracked against a visible backlog
- Quarterly optimization review that retires workarounds rather than documenting them
Not included — True 24×7. Overnight and Sunday incidents are triaged by the duty lead and worked from 06:00 unless a P1 is declared.
Critical
Tier 3Environments where an outage stops production, dispatch, or clinical supply — not just reporting.
- Coverage
- 24×7×365 for P1 and P2; Mon–Sat, 06:00–22:00 Central for P3 and P4
- P1 response target
- 15 minutes
- Everything in Operate, with a follow-the-sun on-call rota
- A named escalation path that ends at a OneVision partner, published in the service schedule
- Quarterly failover rehearsal against the documented runbook, with the result written down
- Written root-cause analysis within five business days of any P1
- Standing capacity for one emergency change window per month without a change order
Not included — Oracle’s own infrastructure. We manage the application, the monitoring, and the escalation into Oracle — we do not run Oracle’s data center and will not claim their SLA as ours.
Service levels
The targets, before you ask for them
Response is time to a person who owns the ticket, not an automated acknowledgment. Workaround is time to something that lets the business keep operating, which is the number that matters during a close.
Draft for review — Standard coverage (Mon–Fri, 08:00–18:00 Central) is confirmed. The response targets, tier names, extended and close-week windows, and the availability figure still need confirming against the master services agreement and the on-call rota.
| Priority | Foundationresponse | Operateresponse | Criticalresponse | Workaround |
|---|---|---|---|---|
| P1 — CriticalProduction is unavailable, or a business-critical process cannot run at all: no invoicing, no dispatch, no payroll, no period close.Updates: Hourly, until a workaround is in place | 1 hour | 30 minutes | 15 minutes | 4 hours |
| P2 — MajorA core process is degraded, or a workaround exists but is not sustainable — the close can proceed, manually, for a few days.Updates: Twice daily | 4 hours | 2 hours | 1 hour | 1 business day |
| P3 — MinorA defect or question affecting individual users, with no material impact on a business process.Updates: Twice weekly | 1 business day | 4 hours | 4 hours | 5 business days |
| P4 — RequestA change, report, or configuration request rather than a fault. Scheduled rather than triaged.Updates: At the monthly service review | 2 business days | 1 business day | 1 business day | Scheduled into the next release window |
Availability
99.9%
Production application availability, measured monthly
Measured as the production minutes in which the application accepted a transaction, divided by total minutes in the month. The numerator comes from a synthetic transaction run every five minutes — not from the absence of tickets.
Excluded from the calculation
- Oracle-declared maintenance windows and Oracle infrastructure incidents, which sit under Oracle’s own cloud SLA
- Change windows you approved in advance
- Outages caused by a change made outside the managed-services change process
- Client network or identity-provider failures upstream of the application
Coverage windows
- Standard
- Mon–Fri, 08:00–18:00 Central. Incidents and requests worked by your named pod.
- Extended
- Mon–Sat, 06:00–22:00 Central on Operate and Critical.
- Close week
- Continuous cover across the five business days around period close, on a rota agreed a quarter ahead rather than arranged in the week itself.
- On-call
- A P1 raised outside coverage hours reaches an engineer directly on Critical, and the duty lead on Operate.
- Holidays
- US federal holidays run on on-call cover. The specific dates are listed in the service schedule rather than assumed.
Transition
Six weeks from handover to a contractual SLA
A support contract that starts billing on day one is a support contract that has not read your environment yet. The SLA clock runs in report-only mode until we have proved we can hit it — every phase below has a stated exit test rather than a date.
- 01
Weeks 1–2
Discovery and documentation
We inventory environments, integrations, customizations, open defects, and the license position — then write the runbook that does not exist yet. Nothing is treated as documented until someone on our side has followed it end to end.
Exit test
A signed environment and integration inventory, a runbook for every recurring job, and a named escalation path on both sides.
- 02
Weeks 3–4
Shadow
Your team keeps the queue and we work alongside them, taking tickets in parallel and comparing resolutions. Gaps in the runbook surface here — while the person who knows the answer is still in the room.
Exit test
Our pod resolves a representative sample of tickets end to end without escalating back to your team.
- 03
Weeks 5–6
Reverse shadow
We take the queue and your team reviews. Monitoring, alerting, and the ticket workflow move to the agreed tooling, and the SLA clock starts running in report-only mode so the first month of numbers is honest.
Exit test
Two consecutive weeks inside every SLA target, with no open handover items.
- 04
Week 7 onward
Steady state
The SLA becomes contractual. Monthly service reviews cover performance against target, the change log, and the optimization backlog. Quarterly reviews cover whether the tier is still the right one.
Exit test
Ongoing — but the first quarterly review is an explicit checkpoint. If the tier is over-specified for what the environment actually needs, we will say so and move you down.
Scope
What the fee covers, and what it does not
Managed services go wrong at the boundary, usually during an incident, usually in writing. So the boundary is here rather than in an appendix you read after signing.
Covered by the monthly fee
No change order, no scoping call.
- Incident triage and resolution for the application and its integrations
- Service requests: configuration, reports, workflow, security roles, and user administration
- Quarterly Oracle update regression testing, with remediation before it reaches production
- Environment refreshes and the clone schedule
- Integration and batch-job monitoring, with alerts routed to a shared channel
- Patch, release, and change management with a documented approval trail
- Monthly service reporting and a quarterly optimization review
Quoted as a change order
Estimated before it starts, never after.
- New modules, or new legal entities brought onto the platform
- Work above an agreed effort threshold — a new integration, a reporting rebuild, an acquisition rollout
- Data migration from a system that was not in the original scope
- Anything that needs a dedicated project team rather than the support pod
Not ours to run
Named so nobody assumes otherwise mid-incident.
- Oracle’s infrastructure, data centers, and platform SLA — that relationship stays between you and Oracle
- Third-party software OneVision did not implement and does not have access to
- End-user desktop, network, and identity-provider support
- Statutory or audit sign-off. We produce the evidence; your auditors form the opinion
What we need from you
- A named business owner per functional area who can make a decision inside the SLA window
- Access to environments, ticketing, and the change-approval path, provisioned before transition starts
- Test resource for quarterly Oracle updates — we regression test, but functional acceptance is yours
- Advance notice of anything that changes the load profile: close timing, acquisitions, audits, peak season
What you get in writing
- Monthly: ticket volume by priority, performance against every SLA target, and each miss with its reason
- Monthly: change log — what went to production, who approved it, and what it touched
- Quarterly: optimization backlog with an effort estimate against each item
- Quarterly: license and consumption position, so a renewal is never a surprise
- On any P1: written root-cause analysis within five business days
Leaving
Everything we write is yours — runbooks, ticket history, change log, and monitoring configuration. Offboarding is a documented 30-day handover with a reverse-shadow period, and it is in the agreement from day one rather than negotiated at the point you want to leave.
Questions
Answered here, not on a discovery call
If something below is still unclear, it is a gap in the page rather than a reason to book a meeting — tell us and we will fix it.
- Do you only support systems OneVision implemented?
- No. We more often inherit somebody else’s build, which is why transition starts with two weeks of discovery and documentation. You will get an honest read on what we find — including anything we would have done differently — before we commit to a service level.
- Can we change tier later?
- Yes, in either direction, at any quarterly review. If the ticket record shows you are paying for cover you have not needed for two quarters, we will raise it before you do.
- What happens during an Oracle quarterly update?
- We regression test in a refreshed environment ahead of the update window, remediate what breaks, and hand your team a test pack for functional acceptance. The window itself belongs to Oracle — we work around it and tell you what changed in the monthly change log.
- Who decides whether something is a P1?
- Either side can declare one. The definitions are written in terms of business impact rather than technical severity, so the test is whether a process has stopped. If we disagree on classification we work it as a P1 and settle the classification at the service review, not during the incident.
- How is it priced?
- A fixed monthly fee per tier, based on module footprint, legal-entity count, and user population, with a stated pool of enhancement hours in the higher tiers. Work outside the pool is quoted as a change order before it starts. No hourly-rate surprises against an open ticket.
- Who is actually on the account?
- A named service lead and a pod of two to three consultants who stay with you rather than rotating through a queue. On the Critical tier the out-of-hours rota is published in the service schedule, with an escalation path that ends at a OneVision partner.
Outcomes
What clients keep after we leave
15 min
P1 response target on the Critical tier
99.9%
Application availability target, measured monthly
6 weeks
Handover to a contractual SLA, with an exit test at every phase
Explore other services
ERP ImplementationEnterprise Performance ManagementStrategy to ExecutionCustomer Excellence SolutionsSupply Chain Excellence SolutionsBack Office Excellence SolutionsHCM & Payroll Integration ServicesAI & AnalyticsProject ManagementProject Rescue & RecoveryIT Advisory ServicesCybersecurity Professional ServicesManagement ConsultingMergers & Acquisitions
Let’s talk about your cloud & ms program
Tell us what it looks like today. We will tell you, plainly, what it would take to fix it — before you sign anything.