The system nobody wants to touch

01 · the-problem

When a system becomes the problem

Every established company runs on software somebody built years ago. It worked, so it stayed. Then the people who understood it moved on, the platform aged out, and now the thing the business depends on most is the thing everyone is afraid to touch.

• The database application only one person still understands
• The aging desktop app that will not install on new machines
• The spreadsheet that quietly runs the whole operation
• The vendor application whose vendor no longer answers

02 · the-approach

Assess, stabilize, rebuild. In that order.

We start with a working assessment, not a proposal: what the system actually does, which parts still earn their keep, and which parts are genuinely holding you back. Then we make the current system safe before changing it. Only then do we rebuild, one working slice at a time.

• Assessment: what stays, what goes, in writing
• Stabilize first: source control, backups, repeatable deploys
• Incremental rebuilds, not big-bang rewrites
• The old system retires only when the new one has earned it

03 · no-downtime

The business keeps running

Modernization fails when it asks the company to stop. So the replacement runs next to the original: data is migrated and reconciled rather than dumped, people learn the new system on real work, and there is a way back at every step.

• Old and new run side by side during the transition
• Data migrated and reconciled, not copied and hoped
• Training on real workflows, not demo data
• A rollback path at every stage

04 · straight-talk

Why we do not open with a rewrite

Some firms open with a full rewrite because a rewrite is the biggest engagement. We think tearing everything out should be a conclusion you arrive at, not an opening position. Rewrites that start from zero throw away years of encoded business rules, and the business pays to rediscover them one bug at a time.

• Keep the parts that work; there are usually more than you think
• Replace the riskiest piece first, end to end
• Every phase leaves you better off, even if you stop there

05 · atlanta

An Atlanta studio, at the table

FiveBox, LLC is headquartered in Buckhead, at 3500 LENOX RD NE STE 1500, ATLANTA, GA  30326, with the team working across the USA and Canada. For Atlanta companies that means the people rebuilding your system can sit at the table with the people who use it, and the people who define the system are the people who build it.

• Atlanta HQ; in person around the metro or fully remote
• Direct access to the people writing the code
• A project starts with us understanding the problem

06 · questions

Common questions

Do we have to replace the whole system?
No, and we will usually argue against it. Most legacy systems have parts that still work well. We keep those and rebuild only what is genuinely holding the business back.

The original developer is gone. Can you still work with it?
Yes. That is the normal case, not the exception. We start by recovering what exists: the source if it can be found, the data, and the behavior people actually rely on, and we document it as we go.

Will the business have to stop?
No. The old system keeps running while its replacement is built next to it. The switch happens when the new system has earned it, not on a leap-of-faith weekend.

What kinds of systems?
Aging line-of-business systems: older Java, Rails, and web applications, desktop-era database apps, spreadsheet-driven operations, and vendor software whose vendor has disappeared.