Digital transformation
The phrase usually arrives attached to a two-year programme and a slide deck. The version worth paying for is narrower: replace the parts of the stack that are actively costing money, in an order that lets the business keep trading, and stop.
What it means
Transformation here means moving a legacy commerce operation onto a cloud-native, API-first footing without a big-bang cutover. Process redesign first, then the architecture that supports the redesigned process, then a phased rollout with the riskiest work deliberately not scheduled into peak season.
The process half is not a soft preamble to the technical work, it is where most of the return is. At Nxtby, introducing structured workflows and approval processes cut development cycle time by 30%, and modelling five-level approval chains for development, B2B orders, quotes and vendor management took 90% of B2B order and quote processing off people, reducing approval cycle time by 40%. None of that required a new platform.
What makes these programmes fail is almost never the technology. It is sequencing: cutovers scheduled by convenience rather than risk, integrations discovered late, and a phase whose success depends on a phase that has not started. Getting the order right is the deliverable.
Problems solved
The symptom as the person with the problem describes it, then what is usually underneath it.
A replatforming nobody wants to start
The risk is not the build, it is the cutover: URLs, redirects, order history, integrations and the week either side. Sequenced properly, trading continues throughout, and the decision stops being all-or-nothing.
The legacy stack is a full-time job
Most of the engineering capacity is spent keeping the current system running, so nothing on the roadmap moves. That ratio is the business case, and it is usually easy to measure.
Every system is integrated with every other system
Point-to-point connections built one at a time until any schema change is an outage. The work is drawing boundaries and service contracts, and it can be done incrementally.
The process was designed around a system nobody uses any more
Approval steps and manual reconciliation that exist because of a limitation removed years ago. Remove those before automating anything, or you automate the wrong thing permanently.
When it applies
Signals it is time
- More engineering time spent on maintenance than on the roadmap
- A platform version far enough behind that upgrading is itself a project
- Integrations that break whenever either side changes
- Processes with steps nobody can explain the reason for
- A commercial plan that assumes capabilities the stack does not have
And when it is the wrong call
If the current system works and the constraint is commercial rather than technical, a transformation programme is an expensive way to avoid a marketing decision. Modernise the part that is costing money and leave the rest alone.
Every one of the six pages under expertise carries one of these. A consultant who recommends everything for everyone is a vendor with a wider catalogue.
Approach
Measure what the current stack costs to run
Maintenance hours, change cost, incident frequency, and the roadmap items blocked. This is the business case, and it is nearly always stronger than the one on the slide.
Redesign the process before the system
Remove the steps that exist because of a limitation nobody has revisited. Automating an unnecessary approval makes it permanent.
Phase by risk, not by convenience
The riskiest cutover gets the calmest trading week and the most rehearsal. Nothing critical lands in peak season, and each phase is independently valuable in case the next one is deferred.
Make the integration boundaries explicit
Service contracts rather than point-to-point scripts, so the next change on either side is a version, not an outage.
Stack
Legacy migrationProcess redesignAPI-first architecturePhased rolloutERP & PIM integrationAWSWorkflow automation
Related work
Full case studies are published on the Raulji Technologies site, which is where delivery lives.
Related writing
Questions
How long does a transformation programme take?
Phase it so that question stops mattering. Each phase should be independently valuable and independently deferrable, which means the programme can stop after any of them without leaving the business worse off. Programmes that only pay at the end are the ones that get cancelled at month nine.
Can the business keep trading during a migration?
Yes, and it should. The risk sits in the cutover rather than the build, so the work is in URL and redirect mapping, order history, integration switchover and rehearsal. Migrations run on that basis are what most of my replatforming experience consists of.
Is digital transformation the same as replatforming?
No, and conflating them is the common expensive mistake. Replatforming changes the system. Transformation changes how the business operates, and often the highest-return part of it needs no new platform at all.
Whether you are scaling an existing commerce platform, planning a migration, exploring headless architecture or looking at AI-driven transformation, the first conversation costs nothing and usually shortens the second one.