Spreadsheets to one source of truth
For a retail group, 50+ Excel files became a single PostgreSQL source of truth.
Change a running system without losing what it knows.
An old system is usually the most accurate description of how the business works, written over years in rules nobody remembers writing. We recover those first, then replace in stages small enough that the operation keeps running.
A practical delivery path
- 01Assess
- 02Stabilize
- 03Rebuild
- 04Migrate
- 05Retire
Nothing is switched off until the replacement has done the same work on the same records and agreed.
What is going wrong before this work starts.
- 01
The system is too risky to touch
Every change threatens reporting, permissions, an integration, or a rule nobody can locate. So the safest available decision is to keep paying for the problem.
- 02
The rules are no longer in the software
Spreadsheets, inboxes, and one long-serving colleague hold what the application cannot. Replace the application on its own and that is what gets lost.
- 03
A clean cutover is not on offer
Everyone agrees the platform is outdated. Nobody can name the weekend when the operation could stop long enough to switch.
What the work includes, start to finish.
- 01
What the current system actually does
Workflows, data ownership, integrations, custom logic, and the undocumented rules, read out of the running system rather than out of a manual that stopped being updated.
- 02
A staged replacement plan
What to rebuild, what to keep and wrap, what to retire, and the order that keeps the operation working through every stage.
- 03
The replacement, engineered on the real process
Interfaces, services, permissions, and data models built on the rules recovered from the old system, including the exceptions it quietly carried.
- 04
Migration, reconciliation, retirement
Records moved with their history, old and new outputs compared until they agree, people trained, and each legacy path switched off deliberately by a named owner.
What this looks like once it exists.
A legacy internal platform
A dated operations tool replaced by a maintainable product that keeps the records, roles, and reporting the business had learned to rely on.
One part at a time
A brittle all-in-one application separated into modules with explicit boundaries, so the riskiest piece could be replaced without disturbing the rest.
Four stages, each ending in something you can see.
- 01
Map
Read the running system: workflows, workarounds, data dependencies, integrations, and the rules that now exist only as behaviour.
OutputCurrent state and risk assessment
- 02
Shape
Define the target, the boundary of each stage, the interim controls, and the smallest release that proves continuity.
OutputReplacement blueprint and cutover plan
- 03
Build
Rebuild in stages, each one reconciled against the old system before anything is allowed to depend on it alone.
OutputReplacement running real work
- 04
Evolve
Retire legacy paths once the operation trusts the replacement, then extend it into what the old system could never do.
OutputA system that can change again
Where this service is usually needed.
Operations Command Center
See where activity, approvals, exceptions, and reporting sit once the spreadsheets propping up the old system are no longer needed.
Open the demonstrationRelated concept demonstration
- 01Assess
- 02Prioritize
- 03Replace
- 04Validate
- 05Operate
Engineering decisions that protect the operation.
- 01
Treat migration, reconciliation, and rollback as product requirements. They are the parts of the project the operation actually feels.
- 02
Carry audit history and record ownership across the move. A record that arrives without its history arrives less trusted than it left.
- 03
Prefer staged replacement over a single cutover unless the workflow genuinely allows the business to stop.
The questions that come up before a project starts.
- Does modernization mean replacing everything?
- No, and it usually should not. The first move is often to stabilize what is failing, lift out the single workflow carrying the most risk, and leave the rest running until it earns replacement.
- How does the business keep working during migration?
- Ownership is decided before anything moves, old and new run in parallel where the risk warrants it, outputs are reconciled until they agree, and every stage keeps a rollback path.
- Can Pixelity work on a system we did not build?
- Yes, and that is the usual case. We read the architecture, the data, and the operational dependencies first, then decide what to keep, what to wrap, and what to replace.
Articles that help frame the decision.
Tell us the process everyone works around.
Describe it in a sentence or two. We will come back with what we would build first, what it would take, and whether you actually need us for it.