Atmora Tech

Engineering

Go-live is easy.
Month-end close is the test.

An ERP programme is a data and process exercise wearing a software costume. The configuration work is finite; the master data cleansing, the reconciliation of thirty years of chart-of-accounts drift and the finance team's trust in the numbers are not.

Overview

SAP, Oracle and Dynamics implementations judged on month-end close, not go-live day.

ERP failures rarely look like software failures. They look like a warehouse that cannot pick because the unit-of-measure conversions were migrated wrong, or a finance team running a shadow spreadsheet six months after go-live because the reports do not tie back. The system is working exactly as configured. That is the problem.

We work standard-first. Every deviation from vendor process is written down with a named owner, a business case and an upgrade cost, and the default answer is to change the process. Custom code in an ERP is a permanent tax paid at every release; some of it is worth paying, most of it is inherited habit from a system replaced two generations ago.

Data migration starts in week two, not in the final quarter. Extract, cleanse and load cycles run repeatedly against the target so the finance team sees their own data in the new system early enough to argue about it. By the time the cutover weekend arrives, the load has been rehearsed at least six times at production volume.

5 days
month-end close at Kestrel Industrial, down from 12 working days
83 to 19
legacy custom developments reduced to approved standard-core extensions
3.1%
master data records rejected at final load, all resolved pre-cutover

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Fit-gap analysis against standard process

    Each business requirement mapped to standard vendor process, configuration, or genuine extension. Gaps carry a cost estimate covering both the build and the upgrade burden it creates for the next decade.

  • Master data cleansing and migration

    Material, customer, vendor and financial masters deduplicated and validated with rules the business signs off. Load cycles are rehearsed repeatedly at production volume, not once during the dress rehearsal.

  • S/4HANA and Dynamics 365 implementation

    Greenfield builds and brownfield conversions across finance, procurement, production planning and warehouse management, delivered by consultants who configure rather than supervise.

  • Extension development on clean-core patterns

    Extensions built on SAP BTP or Dataverse rather than in the core, so upgrades stay routine. Where core modification is genuinely unavoidable, it is isolated, documented and regression tested.

  • Integration with the surrounding estate

    ERP is never the only system. We build the interfaces to your MES, WMS, CRM and banking rails with explicit contracts and reconciliation, because ERP-adjacent failures are the ones that stop shipments.

  • Cutover planning and hypercare

    An hour-by-hour cutover plan with rollback decision points, followed by a hypercare period staffed through the first two month-end closes, which is when the real defects surface.

Deliverables

What you get

  • Fit-gap register with upgrade cost attached to every approved extension
  • Cleansed master data sets with validation rules and named owners
  • Configured environments with documented configuration rationale
  • Interface specifications and reconciliation reports for adjacent systems
  • Hour-by-hour cutover runbook with rollback decision points
  • Two month-end closes supported under hypercare with defect burn-down

Stack

What we build it with

  • SAP S/4HANA
  • SAP BTP
  • ABAP Cloud
  • SAP Fiori
  • Microsoft Dynamics 365
  • Dataverse
  • Oracle Fusion Cloud ERP
  • Odoo 18
  • SAP Cloud Integration
  • Azure Data Factory
  • Power BI

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Process baseline

    Current processes documented against the vendor's standard model, so the fit-gap conversation starts from evidence rather than from departmental preference.

  2. Design and prototype

    A configured sandbox loaded with real extracted data, walked through by the people who will use it daily, with design decisions logged and dated.

  3. Build and migrate

    Configuration, extensions and interfaces built in parallel with repeated migration cycles, each one reconciled to source and reviewed by the data owners.

  4. Rehearse cutover

    At least three full dress rehearsals at production volume, timed to the minute, until the cutover fits the available window with contingency to spare.

  5. Hypercare

    On-site and on-call support through the first two month-end closes, with a defect burn-down published daily and handover only once it flattens.

When this is the wrong engagement

If your core problem is a single differentiating process that gives you commercial edge, forcing it into an ERP's standard model will cost you the edge and the budget.

FAQ

Questions we get asked

SAP, Oracle or Dynamics — which should we choose?

It depends more on your process shape than on feature lists. Discrete and process manufacturing with complex planning tends to favour SAP; service-led organisations with heavy Microsoft estates often land better on Dynamics 365. We run a structured selection with your data, not a vendor demo.

How much customisation is reasonable?

Less than you think you need, and every piece should have a named sponsor and a written business case. A useful rule: if a competitor runs the same process on standard configuration, the deviation is habit rather than advantage. Extensions that survive that test are worth building properly.

Can we do a phased rollout instead of a big bang?

Usually yes, by legal entity, plant or region. Phasing reduces cutover risk but adds temporary integration between old and new systems, plus consolidation complexity at period close. That trade is worth making for multi-site groups and rarely worth it for single-entity businesses.

What happens after go-live?

Hypercare through two month-end closes, then a defined transition to either your internal team or our application support service. The second close matters more than the first: the first is watched by everyone, the second is when people assume it works and stop checking.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project