Digital transformation and legacy modernization: what to change first, and where AI helps

This guide is for owners, COOs, CTOs and IT managers of mid-sized companies whose systems have grown up around the business rather than with it: an ageing store, an ERP bent into shape with spreadsheets, integrations nobody fully understands. It explains how to sequence the work so each step pays for the next, how to choose between rebuild, refactor, replatform and the other options, how to modernize a live system without stopping the business, and where AI speeds up the work or extends the result. It closes with two commerce examples and a risk register you can adapt.

In this guide

• Why sequence matters more than technology
• The three layers of change
• A sequencing model for mid-market companies
• Rebuild, refactor or replatform: the decision
• Modernizing a live system step by step
• Data, integrations and search visibility
• Two commerce examples
• Where AI fits in a modernization programme
• Timelines and what moves them
• A modernization risk register
• Common mistakes
• Limitations of this guide
• Frequently asked questions
• How this guide was made
• Next step

Why sequence matters more than technology

Digital transformation fails less often because of the wrong technology than because of the wrong order. Three patterns recur:

• Platform first, process later. A new system is bought or built, and the old workarounds are copied into it. The company pays for a new platform and keeps the old costs.
• Everything at once. A big-bang replacement touches every team, every integration and every customer at the same date. When it slips, the whole business waits.
• Modernizing what does not matter. Effort goes to the system with the oldest technology rather than the one that blocks revenue, service or cost.

A mid-market company rarely has the spare budget or management attention to recover from these. The discipline is to decide what the business must do differently, then change only the systems that stand in the way, in an order where every step is useful on its own.

The three layers of change

Most transformation budgets are spent at the platform layer, while most of the value is released at the process and systems layers. Work top-down when you plan, and bottom-up only when a platform is at risk: an unsupported version, a security exposure or a vendor exit that forces the timetable.

A sequencing model for mid-market companies

A practical sequence has five stages. Each ends with something the business can use, so the programme can pause without leaving half-finished work behind.

Netbase delivers this kind of programme through a six-step delivery lifecycle, from discovery and architecture planning through agile execution to rollout and ongoing support. Stages 1 and 2 above sit inside discovery; the modernization itself runs in agile sprints with weekly reviews and outcome-based milestones, remote-first from Hanoi in English, with security designed into each slice rather than tested at the end.

For a planning template that turns these stages into a mid-market roadmap, see our digital transformation roadmap guide. When the question is where to start and what to prioritize, digital transformation consulting turns the baseline into a delivery-ready plan.

Rebuild, refactor or replatform: the decision

"Rebuild or refactor" is usually framed as two options. In practice there are more, and the cheapest good answer is often not a code change at all. AWS Prescriptive Guidance lists seven migration strategies, the "7 Rs": retire, retain, rehost, relocate, repurchase, replatform and refactor (re-architect). For application modernization in a mid-market company, five of them matter most, plus the full rebuild.

AWS notes that refactoring is the most complex and costly strategy and recommends, for large migrations, moving first and modernizing after. The same logic helps a mid-market company: separate "get onto a supported base" from "redesign the application" unless one cannot happen without the other.

Five questions settle most decisions:

1. Does the system still fit the target process? If yes, replatform or retain. If no, repurchase, refactor or rebuild.
2. Is the platform supported and secure? If not, the timetable is set for you; replatform first.
3. Is the job distinctive to your business? If not, a packaged product is usually cheaper to own.
4. Can the change happen in slices? If yes, prefer incremental modernization over a single cut-over.
5. Who knows the rules the old system enforces? If nobody, budget discovery before any rebuild.

Data, integrations and search visibility

Three areas cause most modernization surprises. Inventory them before choosing an option.

For online stores, search visibility and order continuity are the two risks that most often decide whether a replatform is judged a success. Our custom e-commerce platform guide covers the replatforming decision and migration planning for stores in more depth.

Two commerce examples

Replatforming: Netztech. Netztech's store ran on Magento 1 and needed a move to Magento 2 without starting over. Netbase migrated it to Magento 2 Commerce. The migration took 35 working days and included an extension migration of 11 modules, covering installation, configuration, customization and data transfer. No performance metric is published for this project; it illustrates the scope and schedule of a replatform where the business model stayed the same.

Read the Netztech migration record

Modernizing without replatforming: Rebelo AG. Rebelo AG, a Portuguese company founded in 1983, did not need a new platform. Its customers could not picture their designs on the finished product, so they hesitated before ordering. Netbase added 3D product previews to the existing online store. Rebelo reported revenue up 39% in the first year, engagement up 98%, conversions in personalized segments up 53% and productivity up 25%. The lesson: target the process blocker first; the platform decision can wait until it becomes the blocker.

Read the Rebelo AG case

Both examples come from online retail and commerce, where the cost of a failed cut-over is counted in lost orders. Read how Netbase approaches storefronts, marketplaces and order operations in retail and e-commerce, and when a store is growing into a multi-vendor model, the e-commerce marketplace solution shows the platform options and the EU fashion marketplace case shows one such move.

Timelines and what moves them

Netbase's typical ranges for e-commerce builds are 1 to 3 months for a small store, 4 to 6 months for a mid-sized one and 6 to 12 months or more for an enterprise platform. These are typical ranges, not quotes. A replatform with few customizations can be faster, as the Netztech schedule shows; a rebuild with many integrations sits at the upper end.

What moves a modernization timeline:

• the number of extensions, custom modules and integrations;
• data volume and quality, and how much history must move;
• how many URLs, reports and downstream consumers depend on the old system;
• how long the business can accept a freeze on changes during cut-over;
• how quickly business owners can make process decisions.

A modernization risk register

Review the register at every stage change. A risk without an owner is still a risk; it is just unmanaged.

Common mistakes

• Buying a platform to fix a process problem. The new system inherits the old workarounds.
• Big-bang cut-overs for systems that could move in slices. One date carries every risk at once.
• Refactoring without a business target. Cleaner code that changes no measure is hard to fund twice.
• Rebuilding without discovery. The old system's unwritten rules reappear as defects.
• Forgetting search visibility. A store that loses its rankings loses the revenue the new platform was meant to grow.
• Ending the programme at launch. Training, rollout and optimization are where adoption is won.

Limitations of this guide

This is practical guidance from Netbase delivery experience, not original research. The migration strategies come from AWS guidance written for cloud migrations and are applied here to application modernization in general; the Strangler Fig pattern is a general architecture approach. Timelines are typical ranges that depend on scope. The AI uses described beyond the 4over4 features are capabilities, not measured results. The Netztech record describes scope and schedule only, and the Rebelo AG results were reported by the client for that project and depend on its baseline and market.

How this guide was made

The Netbase Editorial Team wrote this guide from Netbase's published delivery lifecycle, migration and case-study pages and from public guidance by AWS and Martin Fowler. David (CEO) reviewed every Netbase fact. External sources are cited with access dates. Drafting used AI assistance (Claude). Its purpose is to help a mid-market company modernize in an order where every step pays for the next.

Next step

Share your current systems, the processes that hurt most and any platform deadlines, and we will book a solution review to rank the blockers and propose the first modernization step. You can also see the related service or browse more Netbase insights.

Related services and solutions