The nightly job became nightly: anatomy of a 50-hour data load

A medical-billing SaaS ran its nightly reload past 50 hours

The cluster was fine. The load was not. It had only ever captured part of each day's changes, so every run re-read what it had already read, and the window grew until there was no window.

An engineer embedded in the customer's environment rebuilt the load as incremental deltas. The hardware stayed exactly as it was. The nightly job finished in 20 hours, and application reloads went from 4 of 84 succeeding to near-complete.

Why most projects find this out late

Panorama Consulting Group's 2026 ERP Report studied 170 organizations. More than a quarter of projects went over budget, and the most common cause was an unexpected need for additional technology. Schedule overruns traced most often to organizational issues, not technical ones.

The single most common budget killer is technology nobody scoped, discovered mid-project. A load that quietly re-reads its own data is exactly that class of surprise: a defect set during design that surfaces six weeks before a deadline, wearing a hardware price tag.

What we take from it

The fix is rarely more machines. And the person who owns the outcome has to sit inside the environment with the data and the users. Otherwise the fix lands next to the problem instead of on it.

That is the idea behind our embedded sprint: a senior engineer joins your team for a fixed 30 to 60 day scope, one painful workflow goes into production, and you keep everything built. If a longer technical write-up would help, get in touch.

Sources

• Panorama Consulting Group, The 2026 ERP Report. 170 organizations, data January 2025 to January 2026.
• The engagement numbers (50-plus hours to 20; 4 of 84 to near-complete) are from our own delivery record.