Yuvraj Raulji | 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 makes these programmes fail is almost never the technology, it is the sequencing.
Quick answer
Digital transformation means changing how a business operates using technology, which is different from replatforming, which only changes the system. In commerce it usually covers three things: redesigning processes that were built around a limitation nobody has revisited, moving a legacy stack onto a cloud-native and API-first footing, and drawing integration boundaries so systems stop breaking each other. It suits businesses spending more engineering time on maintenance than on the roadmap. The highest-return part of it frequently needs no new platform at all.
Best suited for
- Legacy stacks consuming most of the engineering capacity
- Businesses whose processes outlived the systems that shaped them
- Operations where every integration change is an outage
- Replatforming that cannot afford to go offline
Business problems
The symptom as the person with the problem describes it, what it is costing, and where the technology actually helps.
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. So the decision is deferred, and the cost of the old system compounds quietly.
OpportunitySequenced properly, trading continues throughout and the decision stops being all-or-nothing. Each phase is independently valuable and independently deferrable, which is what makes it approvable.
The legacy stack is a full-time job
Most engineering capacity spent keeping the current system running, so nothing on the roadmap moves. The business is paying for a team it cannot deploy.
OpportunityThat ratio is the business case and it is usually easy to measure: maintenance hours, change cost, incident frequency and the roadmap items blocked. It is nearly always stronger than the case on the slide.
Every system is integrated with every other system
Point-to-point connections built one at a time until any schema change on either side is an outage. Nobody can say what depends on what.
OpportunityService contracts and explicit boundaries, introduced incrementally rather than in a rewrite. The next change becomes a version rather than an incident.
The process was designed around a system nobody uses
Approval steps and manual reconciliation that exist because of a limitation removed years ago, still being performed daily.
OpportunityRemove those before automating anything. Automating an unnecessary step makes it permanent, and this is where the cheapest return in the entire programme sits.
Approach
Five stages, in this order, on every engagement. Skipping the first one is the most expensive habit in this industry.
Understand
Business modelCustomersProductsOperations
Measure what the current stack costs to run: maintenance hours, change cost, incident frequency, and the roadmap items blocked by it. This is the business case, and it is nearly always more persuasive than the strategic version.
Architect
SystemsIntegrationsCustomer journey
Redesign the process before the system, then draw the integration boundaries the redesigned process needs. Service contracts rather than point-to-point scripts, with the system of record named for every field.
Build
TechnologyExperienceFunctionality
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.
Optimize
PerformanceCROSEOCustomer experience
Carry SEO, order history and integration behaviour across intact. Most of the visible damage from a transformation programme happens at cutover, and almost all of it is preventable with mapping and rehearsal.
Scale
AutomationAIAnalyticsPersonalization
Automate what remains once the process is worth keeping. Introducing structured workflows and approval processes cut development cycle time by 30% on its own, before any AI entered the picture.
Capabilities
Assessment
- Technical due diligence
- Cost-to-run analysis
- Platform selection
- Risk mapping
Process
- Process redesign
- Approval modelling
- Workflow definition
- Role and permission design
Architecture
- API-first design
- Integration boundaries
- Service contracts
- Cloud migration
Migration
- Phased rollout
- Data migration
- URL and redirect mapping
- Cutover rehearsal
- Rollback planning
Operations
- Workflow automation
- Monitoring
- Reproducible environments
- Handover and documentation
AI and technology
What each application does, how it works, where the value is, where a person still reviews it, and what it will not do.
Process discovery from system data
- What it does
- Establishing what a process actually does, from the records systems already keep, rather than from what people remember.
- How it works
- Analysis over order, approval and change logs to reconstruct the real path, including the steps that are skipped and the ones that always stall.
- Where the value is
- It replaces weeks of interviews with evidence, and it consistently finds steps nobody defends once they are visible.
- Where a human reviews
- The business decides which steps to remove. The analysis says what happens; it has no view on what should.
- What it will not do
- It only sees what is logged. Work done in email and spreadsheets is invisible to it, and that is often where the worst of it lives.
Migration data mapping
- What it does
- Matching fields between an old system and a new one, including the ones with no obvious counterpart.
- How it works
- A model proposes mappings from schemas and sample data, flags low-confidence matches, and a person confirms every one before anything runs.
- Where the value is
- Migration mapping is slow, high-volume and error-prone, which is exactly the profile that suits assisted drafting.
- Where a human reviews
- Every mapping is confirmed. An unreviewed field mapping is how order history quietly becomes wrong for a decade.
- What it will not do
- It cannot know business meaning. Two fields with the same name and different semantics look identical to it and will be mapped together.
Post-migration reconciliation
- What it does
- Checking that what arrived in the new system matches what left the old one.
- How it works
- Automated comparison across both sides, with differences classified by type and severity rather than dumped into a spreadsheet.
- Where the value is
- It compresses the riskiest week of the programme. Finding a discrepancy on day one instead of month three is the difference between a fix and an incident.
- Where a human reviews
- Someone decides which side is correct. The comparison reports the disagreement; it does not resolve it.
- What it will not do
- It reports rather than repairs. Automatic correction across a migration boundary is how one bad record becomes a bad dataset.
Architecture
How the pieces sit together, top to bottom. Only technologies actually used appear here.
Current state
Measured rather than described: what it costs to run and what it blocks.
Cost-to-run analysisIncident dataChange logs
Process
Redesigned first, because the architecture should serve the process rather than preserve it.
Workflow modelApproval chainsRoles
Boundaries
Explicit contracts between systems, with the system of record named per field.
API contractsVersioningEvent streams
Target platform
Chosen against the constraints, not the feature list.
Commerce platformERPCMS
Migration
Phased by risk, rehearsed, and reversible for as long as possible.
Data mappingRedirect mappingRollback plan
Infrastructure
Reproducible from configuration rather than assembled by hand.
AWSContainersCI pipelines
Operations
What the business is left running once the programme ends.
MonitoringAutomationDocumentation
When to use it
Good fit
- 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
Think twice
- The current system works and the constraint is commercial
- No executive sponsor who will hold the sequencing when it slips
- A programme that only pays at the end
- Peak season inside the proposed cutover window
- A brief that names the target platform before measuring the current one
Comparison
These are not competing philosophies, they are different-sized answers to different-sized problems, and the expensive mistake is conflating the first two. Replatforming changes the system; transformation changes how the business operates, and the highest-return part of it often needs no new platform at all. If the stack is broadly fine, the third column is the honest recommendation.
| Criterion | Transformation | Replatforming | Incremental modernisation |
|---|---|---|---|
| Changes | How the business operates | The system | One constraint at a time |
| Typical duration | Phased, ongoing | One project | Continuous |
| Risk profile | Spread across phases | Concentrated at cutover | Low per change |
| Pays back | Per phase, if sequenced | At go-live | Immediately, in small amounts |
| Needs new platform | Often not | By definition | Rarely |
| Fails by | Bad sequencing | A bad cutover | Losing momentum |
| Best when | Process and system both wrong | The platform is the constraint | The stack is mostly fine |
| Executive attention | Sustained | Concentrated | Minimal |
Relevant work
Three builds where the work was as much about process and sequencing as about the platform underneath it.
Custom platform · B2BProcurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Web platform · ManufacturingEngineering manufacturer platform
A modern engineering brand platform built for discovery and enquiry.
Web platformTechnical SEOContent
3x traffic growth and 45% better engagement
Magento 2 · MarketplaceMulti-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Business outcomes
30%
Cut in development cycle time
From introducing structured workflows and approval processes into the delivery process itself.
Where this came fromRecorded during the same period as the B2B commerce work. It required no new platform, which is the argument this page is making in a single number.
90%
Of B2B order and quote processing automated
Five-level approval chains modelled explicitly across development, B2B orders, quotes and vendor management.
Where this came fromFrom a high-traffic B2B commerce platform on Magento 2, with a 40% reduction in approval cycle time alongside it. Process redesign and workflow modelling, not a replatforming.
Cost to run
Maintenance hours, change cost and incident frequency. The programme should move all three, and if it cannot be shown to have moved them, it did not work.
Continuity through cutover
The outcome nobody celebrates: the business kept trading, order history survived, and search visibility was unchanged the week after. It is the hardest part to do and the easiest to take for granted.
Both figures come from process and workflow work rather than from a platform migration, and they are quoted that way deliberately. The most useful thing this page can tell you is that the highest-return part of a transformation programme is frequently the part that changes no technology at all.
FAQ
- What is digital transformation?
- Changing how a business operates using technology. In commerce that usually means redesigning processes built around old limitations, moving a legacy stack onto an API-first footing, and drawing integration boundaries so systems stop breaking each other. It is broader than a platform project and often includes no new platform.
- 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 the highest-return part of it frequently needs no new platform at all.
- 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 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 URL and redirect mapping, order history, integration switchover and rehearsal. Migrations run on that basis are what most of my replatforming experience consists of.
- Where should a transformation programme start?
- By measuring what the current stack costs to run: maintenance hours, change cost, incident frequency and blocked roadmap items. That measurement is the business case, and it is almost always more convincing than the strategic narrative it replaces.
- What makes these programmes fail?
- Sequencing, almost never technology. 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 actual deliverable.
- Do we need to replace the ERP?
- Usually not, and it is the most expensive assumption in most proposals. The ERP is generally the system of record and the problem is the integration boundary around it. Fixing the boundary is a fraction of the cost and carries a fraction of the risk.
- How does AI fit into digital transformation?
- After the process work, not before it. Automating a process nobody has fixed makes the wrong process permanent. Once the steps are worth keeping, retrieval, extraction and workflow automation are where the remaining capacity is recovered.
- What if the current system works?
- Then leave it alone. If 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 stop there.
- Who needs to be involved from the business?
- An executive sponsor who will hold the sequencing when it slips, and the people who actually perform the processes being redesigned. Programmes designed only with managers reliably discover the real process during the first cutover, which is the worst possible moment.
Next step
Let us look at your business model, the systems you already run and where you are trying to get to, before choosing the technology. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.