Published 2026-08-04

Requirements for switching platforms: 

The questions that reveal what an e-commerce platform is really made of

Most requirement lists for a platform switch are written as feature lists. Does the platform have PIM? Tick. Does it support multiple currencies? Tick. The problem is that a feature list tells you what a platform has, not how it behaves on the day you actually need to use it. And that's where decisions are really made.

This guide is written for you if you want to ask the questions that separate a platform that holds up from one that looks great in a demo but creates friction in day-to-day work. 

In short:

Strong requirements for switching e-commerce platform are about how the platform performs over time, not how long the feature list is. The decisive questions are about your team's day-to-day independence without developers, architecture and data ownership, AI that both provides insight and does the work, readiness for agentic commerce, and scalability tied to your own growth plans. Execution matters just as much – migration and SEO – as does the question of how much of the solution is standard versus custom code, because technical lock-in is more often found in the code than in the contract. Always ask the vendor to prove their claims live, using your own business as the starting point.

Start with where you are now, not the feature list

Before you write a single requirement, map what you actually have. Not just the features, but the ways of working. A large share of what feels like a "requirement" turns out, on closer inspection, to be workarounds that slipped into operations three years ago and became part of how you work without anyone ever deciding it should.

Then sort the requirements by importance. The list gets long quickly, but force a prioritisation: if you had to choose, what are the ten most important business requirements? Those are the ones you then go through in depth with the vendors you take forward in the process.

• A genuine business requirement. Something the business cannot function without.

• Nice to have. Something that improves things, but isn't decisive.

Also split your needs by time horizon, because that determines what must be in place from day one and what can wait:

• At launch. Must work from day one.
• Within 6–12 months. What you already know is coming, shortly after the switch.
• Within 2–3 years. Growth and expansion needs the platform should be able to grow into.

This split is the single most effective way to avoid falling for shiny features that don't solve your actual problem.

Day-to-day independence: ask them to show it, not describe it

One of the heaviest questions in any requirements process is how much of the day-to-day work your team can do without waiting for someone else. Publishing a campaign page, adjusting a layout, creating a landing page. Almost every vendor says their platform can handle it. Very few are asked to prove it.

So the sharp requirement isn't "do you have a CMS" but "show me, live, how my marketer builds a campaign page without a developer". Ask them to demonstrate it with your type of content, not a polished example. That quickly reveals the difference between an interface built for marketing teams and one that really needs a developer behind the scenes.

Architecture, integrations and data ownership

An open API is a reasonable requirement, but it isn't enough as a question. What determines whether a composable architecture becomes a strength or a burden is how the integrations age and who owns the data when several systems share it.

The strength of composable lies in choosing well. Every component you connect should add clear value, because it's deliberate choices, not quantity in itself, that make the architecture an asset.

Ask directly: what happens when one of the third-party systems is updated? Who is responsible for making sure the integration keeps working, and what does that cost on an ongoing basis? Many e-commerce businesses only realise afterwards that a dozen integrations are quietly holding the entire revenue engine together, and that no one really owns them.

Serkan Selcuk, Product Owner at Viskan, puts it like this: "An open architecture is only worth something if it's crystal clear who owns which data. Time and again, we see that the problems don't arise in the integration itself, but in the interface between systems where no one has really decided who owns the source of truth. Always ask a vendor what data ownership looks like in practice, not just whether the API is open."

How easy will the solution be to move later on? 

One question that's rarely asked during procurement, but says a lot about how free you'll be in future, is how the business-critical parts of your solution are built. Adaptations for your specific business are both normal and necessary in a growing e-commerce operation. The skill lies in finding the balance between following the platform's own logic and meeting the needs of the business, because that balance determines how easy the solution will be to move later on.

You notice the difference on the day you want to switch. What has been built in a standardised way follows known patterns and can usually be recreated on a new platform. What is custom-built in the core, for example in payments or order management, has no ready-made path forward. It has to be understood and rebuilt from scratch, and if you also become dependent on the very people who built it in the first place, the switch becomes even heavier.

That's why it's worth asking how the critical flows are built, and how well anything bespoke is documented. The more of your business-critical core rests on a manageable, standardised foundation, the freer you are on the day you want to move on.

"Lock-in is rarely formal, it's practical. It sits in how the business-critical parts are built. If they're custom-built in a way that only fits your current platform, switching becomes heavy going, regardless of what the contract says. Ask how the core is built and how well it's documented. That tells you more about your freedom to move than anything else," highlights Serkan Selcuk, Product Owner at Viskan.

AI: ask the questions that take you beyond the demo

This is the area where requirements are usually weakest, simply because it's new. And an AI demo almost always looks good. The real difference between platforms isn't the model, because by 2026 almost everyone has access to the same underlying models. The difference lies in everything around it: the data feeding the AI, how deeply it's integrated, and whether it can act on its own conclusions or only suggest them.

Three questions that cut through the noise:

1. Does the AI reach the systems that are supposed to act on what it finds? 

Or does it stop at a recommendation that someone still has to carry out manually? The difference is concrete: an agent that increases exposure for a product that's suddenly selling well, without you having to do anything, is something entirely different from one that simply reports it.

2. Does the AI actually do work for your team? 

Can it generate product copy, translate and localise content into all your languages directly in the platform? That's where AI takes manual work off your plate – the kind that otherwise never ends.

3. Who can use it, and what is it evaluated on?

Can your e-commerce team benefit from the AI without technical help, and is it measured on real outcomes such as conversion and time saved, rather than the number of features?

"It's easy to be impressed by an AI demo. The harder question is what happens after the demo: does the AI reach the systems that are supposed to act on what it suggests, and can your team use it without technical help? An AI feature that can't do anything with its own conclusions is a demo, not a feature." explains Serkan Selcuk, Product Owner at Viskan.

Is the platform ready for agentic commerce?

At its core, agentic commerce is about another channel emerging, where the purchase itself happens via an AI agent rather than someone clicking through your site. It's worth including in your requirements already, even if purchases aren't happening there at scale yet.

Two questions: one matters today, and the other is about where things are heading:

• Are you visible where the purchase journey starts? More and more buying journeys begin in an AI assistant rather than a search box. Are your product data and your site built so an agent can find, understand and present your products correctly? That depends on technical performance and structured data, and it already affects your visibility today.

• Is there a path to completing purchases? Ask the vendor directly whether they have a roadmap for handling purchases made via agents. You don't need the feature tomorrow, but the answer says a lot about how forward-looking the platform is.

Scalability: ask them to work from your numbers, not theirs

"The platform is scalable" means nothing on its own. Scalability is always relative to your specific business. Useful requirements take your own growth scenarios and ask the vendor to show how the platform behaves under them:

• How does the platform behave with double the product catalogue and several times the traffic?

• What does it take to go from B2C to hybrid B2B, or to add a subscription model?

• What does expansion into a new market mean in practice, beyond changing the language: local payment and delivery methods, currency and market-specific campaigns?

If the answer to every new need is "another module", it's worth calculating what that costs over time, both in money and in performance.

The switch itself: migration, SEO and risk

The switch is the single riskiest moment for your e-commerce revenue, and yet it's often the least rigorously defined. Most things that go wrong aren't about a missing feature, but about what happens in the transition. So define the execution just as rigorously as the platform itself:

• How will the data migration be handled, and can it happen in stages so you can validate it in rounds?

• Is there a risk the store will be down during the transition, and if so, for how long?

• How will your SEO be protected – URL structure, redirects and metadata – so you don't lose the visibility you've built up over years?

Ask for a concrete plan, not reassurance that "it usually goes well".

The vendor becomes your partner, not just your platform 

You're buying a relationship, not just a product. Two platforms that look identical on paper can behave very differently on the day something breaks.

Ask how support actually works in practice. The difference between ending up in an anonymous ticket queue and quickly reaching someone who knows your solution can be measured in weeks when it really matters.

Also ask who you'll be working with over time. A dedicated contact who knows your business is worth far more than support capacity. Someone who understands your operation also knows which new features are relevant for you, and can feed your needs into the platform's development. That leads to the next question: how is the platform evolving, and do you get access to new functionality on an ongoing basis? A platform that develops continuously, where every customer benefits from the improvements, stays relevant over time instead of slowly falling behind.

Finally, ask how upgrades are handled, because the difference between automatic upgrades and version changes that become projects in their own right is a recurring cost you'll pay for years. And ask to speak to existing customers, ideally without the vendor in the room. It's the most honest source of information you'll get.

What matters most doesn't show up in the feature list, but in how the platform performs over time

Above all, good requirements do one thing: they shift the focus from what a platform promises to how it performs over time. If you ask these questions, you can separate vendors long before any contract is signed.

If you'd like to talk through what makes sense to include in your requirements for your specific business, we're happy to talk. No sales pitch, just a conversation about where you are.

Article experts