Ecommerce replatforming: choosing for European markets

Ecommerce replatforming for multiple European markets is a business decision, not simply a technical upgrade. Choosing a delivery partner means finding a team that can connect technology, operations and commercial objectives. Start with the operating model you need to support, today and when you add another market.

Languages, currencies, payments, stock availability and returns all shape that decision. A service that is straightforward to launch may become expensive to operate. Extensive custom development can introduce complexity before it is useful.

Compare practical scenarios rather than feature lists. Separate what must work at launch from what can follow later.

Ecommerce replatforming starts with requirements, not a demo

A demo presents an orderly journey. Daily operations involve exceptions: products restricted in certain territories, different price lists, amended orders, incomplete translations and split shipments.

An ecommerce consultant should start with these situations. Before requesting a proposal, build a shared requirements map with leadership, marketing, finance, logistics and customer support. Each function should explain its needs and identify who will own the work.

Separate requirements into:

• Essentials: capabilities without which the commercial model cannot operate.
• Recurring tasks: frequent activities that must be manageable and easy to check.
• Planned developments: markets, channels or services not needed at launch.
• Constraints: budgets, existing contracts, systems to retain and available skills.

Give each requirement a testable outcome. “International capabilities” says little. As a hypothetical acceptance criterion, “the commercial team can update a local price list without changing other markets” can be demonstrated and checked.

In our eCommerce development work, this analysis shapes the project around our partners’ organisations. Technology should support the operating model, not impose one.

Total cost of ownership: look beyond the initial proposal

Total cost of ownership covers everything needed to keep the shop usable and maintainable. Subscription fees or development costs are only part of the assessment.

Compare the full scope

Include configuration, design, data migration, integrations, translation, training and testing. Then examine hosting, licences, external services, maintenance, support and updates, checking what each proposal actually includes.

Clarify any transaction-related charges. Distinguish fees associated with the technical solution from those charged by payment providers.

Internal time matters too. A process requiring repeated manual intervention still costs money, even when it does not appear on a supplier’s invoice. It uses staff capacity that could support other work.

Test comparable growth scenarios

Ask suppliers what changes as orders, catalogue size, staff accounts and markets increase. Which costs rise? Which capabilities require a different contract? Which changes need additional development?

Assess exit costs as well: exporting data, obtaining documentation, transferring integrations and maintaining continuity. A low entry price is less attractive if changing supplier becomes difficult.

Compare proposals against the same functional and operational scope. Make exclusions, responsibilities and growth assumptions explicit rather than treating them as details to resolve after signing.

Managed service or bespoke development: choose the control you need

A software-as-a-service model provides a managed service within defined technical and contractual boundaries. Bespoke development allows more specific behaviour, but brings wider responsibilities for security, maintenance and future changes.

Neither is inherently better. The boundary is not absolute: managed services may support custom integrations, while bespoke projects may use standard components.

Criterion	Managed service	Bespoke development
Commercial processes	Check how closely available functions fit	Can support distinctive processes, with more design work
Technical management	Some responsibilities are included, subject to contract	Infrastructure and maintenance need explicit owners
Customisation	Limited by available extension options	Greater freedom, alongside development and testing costs
Future changes	Also depend on the provider’s decisions	Depend on team capacity and available budget
Portability	Check exports, access and contractual restrictions	Check code ownership, documentation and transferability

For relatively standard selling processes, a managed service may reduce the initial technical workload. Where competitive advantage depends on particular commercial rules, additional customisation may be justified.

Hypothetical example: a manufacturer with complex product configurations and quotations approved by its sales network may need a different approach from a consumer brand selling a uniform catalogue. Business size alone should not determine the architecture.

Multiple languages and currencies: design for markets, not translations

A market is not the same as a language. Countries sharing a language may need different assortments, commercial terms, payment methods and delivery options.

Check whether the proposed solution can manage these differences without unnecessarily duplicating work. Examine shared content, local adaptations, price lists and staff permissions separately.

Languages, content and organic visibility

Google’s guidance on multi-regional and multilingual sites explains approaches to making language and regional versions recognisable. Consider distinct URLs, links between versions and appropriate annotations during architecture planning, rather than treating them as later corrections.

Establish who updates translations when product information changes. Publishing several languages has limited value without a process for keeping information, availability and terms consistent.

Currencies, payments and local terms

Displaying a converted price does not necessarily mean accepting payment in the local currency. Ask how charges, rounding, refunds and financial reconciliation work.

Hypothetical example: a business serving the UK and Ireland may reuse some English-language content, but should not assume identical operations. Tax, customs, delivery and returns need review by qualified advisers, taking account of the seller’s location and the movement of goods.

Planning for international expansion connects these choices to the commercial viability of entering each market. Localisation is an operating responsibility, not just a translation task.

Integrations, scalability and internal skills

An integration listed in a proposal does not prove that it covers your business process. Establish which data moves, in which direction, how frequently and what happens when the transfer fails.

Map the flows between business management systems, warehousing, payments and support. Each data type needs an authoritative source. Where are prices set? Which system determines available stock? Where is a refund recorded?

Testing should cover failures as well as successful transactions: duplicate orders, interrupted connections, missing products and partial updates. Specify understandable alerts, recovery procedures and clear responsibilities.

Grow without losing operational control

Scalability is not only about traffic. It includes adding catalogues, staff, promotions and markets without making everyday management fragile.

For the shopping experience, web.dev’s Core Web Vitals guidance provides reference points for loading performance, responsiveness and visual stability. Measure representative pages and journeys, including on mobile devices.

The W3C Web Content Accessibility Guidelines provide a reference for accessibility. Navigation, forms and checkout should be part of design and acceptance criteria, not checked only at the end.

Finally, assess internal skills. Who can change a promotion? Who investigates an anomaly? Which tasks require supplier involvement? A sustainable solution gives people appropriate autonomy, backed by responsibilities and training that match the resources available.

When to migrate and when to improve what you have

Sales below expectations do not demonstrate that the underlying technology is wrong. The problem may lie in the offer, acquisition, content, logistics or purchase journey.

Migration becomes a reasonable option when structural limits are documented: markets that cannot be supported, unstable integrations without a sustainable remedy, excessive manual work or restrictions blocking necessary development.

Compare concrete alternatives before committing: improve the existing implementation, replace a component or migrate. Assess expected benefits, costs, risks and organisational impact for each. Rebuilding is not a guarantee of growth.

Plan continuity before development

A migration plan should include a data inventory, catalogue clean-up, order-history transfer where possible, access management and end-to-end workflow testing. Define which information must move and validate the results rather than assuming a successful import means accurate data.

To support organic search continuity, include URL mapping, redirects and checks on language and regional versions. Involve eCommerce SEO before development decisions make those tasks harder.

Complete the plan with a launch procedure, anomaly monitoring and a recovery approach compatible with the technical constraints. Agree who can authorise launch, who handles operational issues and what happens if a critical flow fails. These are practical safeguards, not reasons to assume migration will be risk-free.

Common mistakes and a decision checklist

Weak decisions usually start with incomplete comparisons: choosing from a demo, considering only the initial price, mistaking an available extension for a resolved process, or commissioning custom features that reproduce inefficient habits.

Another mistake is postponing international requirements indefinitely without checking compatibility first. You do not need to build everything immediately, but you should avoid decisions that make planned expansion unnecessarily expensive.

Before approving the project, use this checklist:

• Priority markets and essential requirements are agreed across the business.
• Demonstrations use operational scenarios relevant to the business model.
• Proposals identify recurring costs, exclusions and responsibilities.
• Languages, currencies and local terms have been assessed separately.
• Integrations include error handling and data reconciliation.
• The internal team has tested its most important daily tasks.
• Performance, accessibility and organic visibility are included in acceptance testing.
• Access to data, documentation and code where applicable is clearly defined.
• Launch plans include training, support and incident management.

The best choice does not eliminate every compromise. It makes acceptable compromises visible and assigns responsibility for those that need managing. That gives decision makers a clearer basis for approval than a feature comparison alone.

Sources

• Google: managing multi-regional and multilingual sites
• web.dev: Core Web Vitals guidance
• W3C: Web Content Accessibility Guidelines

If you are considering ecommerce replatforming or a new online shop, talk to us. We can start with your markets, processes and constraints to compare realistic alternatives before choosing the technology.