E-commerce platform consulting is the work of deciding which platform your store will run on — or when and how to leave the one you have — by looking at how your business flows rather than at a feature list. The right decision rests on four questions: how complex are your catalogue and order structure, which systems does the store need to talk to, who will change the store and how often, and what scale will you be at in two years? The platform name is the result of those four answers; start from the other end and the decision becomes a preference rather than a reasoned choice.
Okan is in charge of e-commerce at a sports equipment brand. He is unhappy with the platform they moved to a year ago, and on his desk is a feature comparison of three platforms: a tick in every row, a price in every column. Not one row asks the question that sent them moving last year: why are dealer orders still typed in by hand?
I invented Okan for this article; I did not invent his situation. Most buyers who want to change platform hope the new one will solve the problem the last migration did not. In this article I go through the criteria behind a platform decision, the choice between your own site and marketplaces, when to leave your current platform, the risks of migration and the questions to ask a consultant. I do not compare specific platforms' prices or features: that information changes often, and it is not what decides your choice anyway.
This article is the "how it works" part of the e-commerce decision set. How to choose the consultant is in how to choose an e-commerce consultant, what the decision and the build cost in the e-commerce consulting pricing article, and how we make the platform decision on our e-commerce consulting service page.
What does e-commerce platform consulting decide?
Three decisions: the type of platform, the structure of your sales channels and the timing. An off-the-shelf platform, one running on your own server, or custom development? Your own site only, marketplaces only, or both? Stay on today's platform and improve it, or leave?
The third decision is the one most often skipped. One of the honest answers in platform consulting is "don't change": the problem is often not in the platform itself but in an accounting program that is not connected to it, a stock list kept by hand, or measurement that was never set up. In that situation a new platform moves the same problem somewhere more expensive.
What is the difference between an off-the-shelf platform, a self-hosted platform and custom development?
The difference lies in which part of the work stays with you and which with the provider. On an off-the-shelf platform, hosting, security and updates are the provider's job; the build is fast and the maintenance load is low, but changes to areas such as the theme and the checkout step go only as far as the platform allows. On a platform running on your own server, flexibility grows, and in return hosting, security updates and maintenance become your or your team's responsibility. With custom development anything is possible, but every change is development time, and the system's life depends on a team to sustain it.
There is no general ranking among the three. For a store selling standard products with a few integrations, an off-the-shelf platform is usually the cheapest and fastest route. If there is complex pricing, a dealer hierarchy or heavy ERP integration, custom development or a strong integration layer starts to earn its place. There is also a route in between: completing what the platform lacks with a module, without changing the platform.
A real example of this middle route is the MKComputer case. The platform was built on Magento 2, but the real work was done not by Magento itself but by a custom module written against the supplier's data format. Stock, price and supplier data for more than 200,000 products had to be refreshed at short intervals, and a general-purpose import extension could not meet the volume and freshness requirements at once; with the custom module, the catalogue came to update automatically every 5 minutes.
What criteria should a platform choice rest on?
Six criteria are enough, and behind each one is a question answered in your business, not on the platform's website.
- Catalogue structure: how many products, how many variants, which filters? Products searched by specification (memory, size, compatibility) and a few hundred standard products do not create the same platform needs.
- Order volume and campaign peaks: what will the platform do not on an ordinary day but on the busiest campaign day? A setup that jams when product count or campaign volume rises shows its problem on the most expensive day.
- Integrations: card payments and instalments, e-invoicing, accounting or ERP, carriers, marketplace orders. For each one, does the platform have a ready connection, or does it need separate development?
- B2B and dealer rules: if you need dealer-specific pricing, bulk ordering, account balances and deferred payment, can the platform carry them, or will a separate system be built alongside it?
- Change frequency and ownership: who will change what on the store every week? A setup where the marketing team can open pages on its own and one where every change goes to a developer do not carry the same cost.
- Ownership and exit: can you export your product, customer and order data in full? Choose assuming that one day you will leave the platform you are entering today.
If you sell abroad, a seventh criterion is added: can currency, language, tax and shipping rules work separately in each market? In the survey of 108 sellers by iyzico, Dogma Alares and ETİD (Türkiye E-Commerce Ecosystem 2025), 35% of sellers actively sell abroad and 44% name selling abroad and going global as a challenge. In a multi-market store the platform decision means thinking of each market as a separate store.
None of these criteria ignores price; but price is not a criterion, it is the result of the criteria. Calculate the two- or three-year total cost with the build, subscription or hosting, add-ons, development and maintenance hours and your team's time; I have written out how to do that line by line in the e-commerce consulting pricing article.
Your own site, marketplaces, or both?
According to the survey of 781 businesses in the Ministry of Trade's 2025 e-commerce outlook report, published on 12 May 2026, 48.8% of businesses sell both on their own site and on marketplaces, 39.5% only on marketplaces and 11.7% only on their own site. In other words, roughly half of the businesses surveyed use both channels, and the question is usually not "which one" but "how will both run in one routine".
The two channels give different things. A marketplace brings ready demand and trust, but most of the storefront, the customer relationship and the rules are in the platform's hands. Your own site leaves the brand story, customer data and pricing decisions to you, but you bring the traffic yourself. Platform consulting's job here is less choosing channels than making sure every order, wherever it comes from, is processed in the same stock, invoicing and shipping flow; otherwise every new channel multiplies the manual work. How marketplace orders distort your site conversion rate is covered separately in the e-commerce conversion rate benchmarks article.
At OdorGo the two channels were set up together: the e-commerce site was opened on İKAS, and the Trendyol and Hepsiburada storefronts were tied into the same measurement frame. In a category campaign the effect was recorded on the channel where the purchase happened, not where it was seen; reading channel by channel would have hidden which film drove which sale. In eight months e-commerce, marketplace, retail and stand sales together reached ₺10M in revenue.
When should you leave your current platform?
You should leave when the constraint is structural: when the platform cannot express your business rules, will not let you build a necessary integration by any route, cannot carry the load on a campaign day, or prevents you from exporting your data in full. If the constraint is not structural, leaving does not solve the problem; it moves it.
The situations that do not justify leaving are just as clear. If few visitors arrive, the work starts with performance marketing; if visitors arrive but do not buy, with conversion optimisation; if the product pages are weak, with content; if orders are processed by hand, with integration. None of these needs a new platform. Ask yourself this: of the changes you wanted to make in the last six months and could not, how many were really blocked by the platform, and how many by time, budget or know-how?
What are the risks of a platform migration?
The risks of a migration collect in five places: data, addresses, integrations, measurement and the team. None of them makes a migration impossible, but none of them solves itself.
- Data: products, variants, images, customers and order history have to move in full and correctly mapped. A variant moved incompletely means wrong stock.
- Addresses: if product and category URLs change, every old address has to redirect to its new equivalent; a migration without redirects can restart the visibility built up in search engines from zero.
- Integrations: payment, invoicing, accounting, carrier and marketplace connections are rebuilt on the new platform and each one is retested with a real order.
- Measurement: if the analytics events are not rebuilt, before and after cannot be compared, and the way of knowing whether the migration worked is lost.
- The team: a new admin panel needs new habits; training on adding products, managing orders and reading reports is part of the migration, not something after it.
We lived through the address risk on our own site. We moved our site to a new platform on 29-30 August 2026 and redirected the old addresses to the new pages. When we checked Search Console twenty days later, none of the four old service addresses we inspected had been recrawled since the move: Google had not yet seen the redirects and did not know some of the new pages at all. We gathered the old addresses into a separate sitemap and resubmitted them to Google. The lesson: setting up redirects is half of the migration; the other half is monitoring, for weeks, that the search engine has seen them.
How is a migration planned?
A migration is not a date; it is a sequence. First comes the inventory: data to move, integrations to build, addresses to redirect and measurement events to rebuild. Then the mapping: where each field in the old system lands in the new one is written down. Then testing: each integration is tried with a real order, each redirect one by one.
The go-live date is not chosen independently of the campaign calendar. In the Ministry of Trade's data, e-commerce's share of total trade was 19.3% across 2025 but rose to 22.4% in November; migrating that month means handing the heaviest traffic to the least tested system. Nor does the store have to open all at once: the critical flow — product, basket, payment and order — goes live first, and the rest is added on top. The first orders are watched, and the old and new systems are read side by side for a while.
Take a baseline before the migration too. If you do not record your current store's mobile speed, checkout friction and tracking tags, you will not be able to say after the migration whether the new system is better. Diagnoo keeps part of that record for free: it scans seven key pages, reads mobile LCP, CLS and TTFB from PageSpeed Insights and lists missing tags by name. Repeating the same scan after the migration lets you make the comparison in numbers.
Which questions should you ask a platform consultant?
Eight questions show whether the consultant bases the platform decision on reasoning or on habit.
- What information do you need before recommending a platform to us?
- Do you give the options you ruled out, and why, in writing?
- Which items do you include in the two- or three-year total cost?
- Do you receive commission, partnership or referral income from any platform?
- Who prepares the redirect map for old addresses in a migration, and for how many weeks do you monitor afterwards?
- Which data will be moved, which cannot be, and when will we find out?
- How do you choose the go-live date against our campaign calendar?
- Have you ever advised a client not to change platform?
The eighth question yields the most. A platform consultant who has never said "don't change" is giving every problem the same answer. I have gathered the general selection criteria separately, in ten questions, in how to choose an e-commerce consultant.
Who needs a platform consultant, and when?
A platform consultant earns their keep in front of a decision that is expensive to reverse. There are five typical moments: setting up the first store, when the risk of choosing the wrong platform is highest; when growth makes the platform jam under product count or campaign volume; when the dealer and wholesale channel is to move onto the site; when opening to markets abroad, as currency, language and shipping rules diverge; and when the accounting or ERP system changes and the store has to connect to the new one.
There is also a moment when you do not need a consultant: if you sell standard products, have only a few integrations and your current platform carries today's business and the near future, what you need is not a platform consultant but a good implementer. Saying so is part of the consultant's job; a consultant who does not is selling the project, not the decision.
How does INDOLES make the platform decision?
We discuss the platform name last. In e-commerce consulting the platform is only one of the four axes we look along; the other three are ad channels, operating system and growth. First, the order flow from entry to delivery and the manual work along the way are mapped; the platform decision comes after that map, comparing off-the-shelf and custom options on cost, timeline and growth scenario. The output of this stage is a written platform decision, a cost comparison and a build plan.
İKAS, Ticimax, İdeaSoft, Shopify and WooCommerce builds sit inside our service; at MKComputer we wrote a custom module on Magento 2, and at OdorGo we built the site on İKAS. Our answer to the fourth question: INDOLES is a reseller of the İKAS e-commerce platform; because that tie could sway the recommendation, the options ruled out are written down with the decision, and İKAS is not the answer for every project. We make the platform decision on catalogue size, order volume and integration needs rather than brand preference; if your current platform is on that list, the work starts not from scratch but from the breakpoints found in the flow map. If the constraint is on the operations side, the Digital Transformation Audit maps order flow, inventory and customer communication in three weeks and leaves a separate spec, including tool selection, for each recommendation. The details are on our e-commerce consulting service page.
Conclusion: the test to run before discussing platform names
E-commerce platform consulting is not a feature comparison; it is a decision discipline. The right platform is the one that carries your catalogue structure, your integrations, your way of making changes and your two-year scale. Sometimes that is the platform you already have.
Here is the concrete test you can run today: make two lists. The first: every system an order touches — platform, payments, accounting or ERP, carriers, marketplaces. The second: every change you wanted to make in the last six months and could not, with the reason. If most of the second list is platform limits, you have a platform question. If it is time, budget or know-how, your question is not the platform; a new one would move the same list to a new admin panel.
Bring the two lists to us too. How we make the platform decision in e-commerce consulting is written out step by step on the service page; the first meeting starts with those two lists.