Is the migration really needed

A slow store doesn’t necessarily need a new platform. The cause may be inefficient queries, unsuitable hosting or a specific plugin. Outdated stock levels may come from the integration, and wrong prices from inconsistent data. Moving the same rules and data to another system will keep the source of the trouble.

Write the problems down as observable situations. For example: an import blocks work in the admin panel, a price update takes too long, staff manually correct the data of every order. Then compare the cost of fixing the current solution with a migration. In both options there should be a defined outcome and a way of checking it.

A migration is justified if the target system handles the necessary processes better and the benefit outweighs the cost of moving and of later maintenance. Check this with a demonstration of the hardest scenario. The PrestaShop vs WooCommerce comparison will also help you put the criteria in order.

What needs to be inventoried

First create a register of data and features. For each item, state the source, the destination, the transfer method and how it will be checked. Note whether the data is still being changed in the live store. This lets you separate the initial catalogue load from topping up orders and customers just before the switchover.

• Products, variants, SKU and EAN identifiers, prices, stock and relationships between items.
• Categories, brands, attributes, images, attachments and descriptions in each language.
• Customer accounts, addresses, groups and consent information, with its context.
• Orders, line items, discounts, payments, statuses and document numbers.
• Reviews, information pages, blog articles and downloadable materials.
• Coupons, gift cards, loyalty points and extension data, if they are used.

WooCommerce has a built-in CSV product export, described in the importer and exporter documentation. Such a file is a source of product data, not a complete functional copy of the store. Order, customer and extension data need a separate solution and mapping to the PrestaShop structure.

Automate repetitive data transfer, but agree the mapping of fields and exceptions by hand. Check a sample that also includes unusual records: a product without an image, a multi-variant bundle, a customer with several addresses or a partially refunded order. A matching record count doesn’t prove that their meaning has been preserved.

Order history and documents

Decide whether the full history should go into the new admin panel or whether part of it will stay in a secured archive. Either option must let staff find an earlier purchase and resolve a customer’s request. If the old system stays in read-only mode, agree who will maintain it, secure it and give authorised employees access.

Don’t recalculate historical orders using new price lists and current tax rules. The migrated history should keep the values recorded at the time of purchase. Check totals, discounts, delivery costs and links to payments. The order number in the new system may differ from the old one, so you need a permanent mapping between the identifiers.

Documents issued in the previous system should not be treated as new orders to be invoiced again. Agree how the originals can be accessed and the scope of migration with the people responsible for accounting and customer service. Also check that importing the history won’t trigger emails, automations or an export to the ERP again.

URLs and Google visibility

Before the move, collect URLs from the sitemap, analytics tools, Search Console and logs. For every important URL, define its new equivalent. Don’t limit yourself to products: traffic may lead to categories, guides and older campaign pages. The list should be ready before the old store stops being available.

Google recommends mapping URLs and using permanent redirects to the corresponding new pages. Redirecting everything to the home page in bulk may be treated as a soft 404. Internal links, canonical tags and sitemaps also need updating. These principles are described in Google’s site move documentation.

Assess filters and pagination separately. Not every technically accessible URL should become a separate landing page. Check which views have content and meaning for the user and which merely duplicate the catalogue. Make indexing decisions deliberately instead of automatically recreating all the old parameters.

Before launch, check a sample and an automated response report for the whole prepared map. A redirect should lead to the right, working page without an unnecessary chain. When URLs change, visibility may fluctuate for a while; there is no guarantee of identical rankings. It is worth limiting simultaneous changes to content and structure so the effects of the move are easier to assess.

Differences an import won’t handle

A product variant must keep its own identifier, stock, price and link to images where they are separate. The name “size” in two systems doesn’t guarantee that the whole structure matches. Also check units, bundles and personalised products. A configuration built with a plugin may need a separate module or a rebuild.

Compare taxes, discounts and delivery costs on the same carts. Pay attention to rounding and the order in which promotions are applied. A matching price for a single product isn’t enough if the discrepancy only appears with several items and a coupon covering part of the order.

Customer accounts and passwords are two different tasks. Moving the email address doesn’t mean the new system will correctly verify the old password hash. Check the actual authentication mechanism of both installations. If a compatible password migration isn’t available, prepare a secure way to set a new password and clear communication. Never export or send passwords in plain text.

The blog can stay on WordPress or be moved to an agreed tool. This decision affects URLs, menus, search and the editorial team’s work. Don’t assume that the store’s target platform will automatically reproduce every feature of the current site.

Sales switchover plan

1. Launch a secured target environment and isolate its payments, email and integrations.
2. Run a trial migration, keeping an error report and an identifier map.
3. Check the data and complete processes together with the people who run the store.
4. Repeat the trial on fresh data and measure the time needed for the final operations.
5. Set the moment when changes and orders are paused, and how payments in progress will be handled.
6. Transfer the remaining data, enable the redirects and run a production test.
7. Confirm that monitoring works and that the team is ready to handle reports.

The rollback plan must state the point up to which a simple return is possible. Once the new store starts taking orders, restoring the old database without reconciling the data may lose them. Agree who will make the decision and how transactions accepted after the switchover will be secured.

The first two weeks after migration

Check payments, order handover, stock updates and customer reports every day. A transaction error needs an immediate response. Don’t wait for a bigger data sample if the provider takes the money and the store doesn’t save the confirmation.

Also watch 404 errors, indexing and traffic on important pages. When comparing conversion, take into account whether the analytics is correct and the traffic sources. A drop in recorded purchases may come from a measurement error, but that has to be confirmed with order data. Keep observations separate from hypotheses and record the fixes you make.

Appoint one person to collect reports after launch. For each one, record the URL, the action, the expected result and the order number if the problem concerns one. With a shared list, customer service and developers won’t be investigating the same case in parallel across several channels.

Frequently asked questions

Will I lose my Google rankings?

Unchanged rankings can’t be guaranteed. A URL map, proper redirects and indexing checks reduce the risk of technical errors. Changes to content or structure need an additional assessment.

Will customers keep their accounts and passwords?

Accounts can be moved once the data mapping is agreed. Keeping passwords depends on the compatibility of the mechanisms and the chosen migration solution. If they aren’t compatible, plan for customers to set new passwords.

How long does a store migration take?

It depends on the data, integrations and functional differences. The timeline should include a trial migration, fixes and testing by staff. The import itself is only one stage.

Does the store have to be offline the whole time?

No. Preparation and most of the trials run in parallel with sales. At the end you need to agree a short period of controlled switchover and a consistent transfer of changes.

Before getting a quote, prepare a list of data, integrations and your hardest orders. It will help define the real scope of the store migration and check whether changing platforms pays off.

Artykuł Migrating from WooCommerce to PrestaShop: what needs to move pochodzi z serwisu eCommerce Expert.

What really makes a B2B store complicated

Selling to businesses can look like an ordinary retail store with prices shown after login. It can also involve a customer with many branches, different buyer roles, limits, manager approval and negotiating part of the order. Both models are called B2B, but they require a different scope of implementation.

Before comparing platforms, describe the rules with examples. What does a customer’s employee see, and what does their manager see? Does the discount depend on the product, quantity, contract or account balance? What happens when a credit limit is exceeded? Can a salesperson change the offer, and does the customer have to approve it again? These answers define the structure of the system.

Also take into account the work after purchase. Partial availability, delivery from several warehouses, splitting an order and correcting an address all affect fulfilment. A choice based only on how the catalogue looks misses the place where the team may be doing the most manual work.

Where PrestaShop may be enough

PrestaShop offers specific prices, which can be tied to, among other things, a customer, a group and a product quantity. The vendor describes their configuration in the specific prices guide. So the need for an individual price is not yet in itself an argument for building a more complex solution.

If the company has a repeatable purchase process, clearly defined price groups and an ERP integration, check this option first. You need a trial on real rules: a customer with a contract price, a quantity threshold, a promotion and a change in the number of items. See whether the result also matches after the order is passed to the sales system.

Additional features may require modules. For each, check the vendor, updates, compatibility with the version you use and how it works with other add-ons. Several extensions don’t have to be a problem. The difficulty arises when several independent elements try to decide on the same price or order status at the same time.

Don’t set the threshold at, say, a hundred or five hundred business customers. A larger number of companies using one simple rule can be easier to handle than a small group with different purchasing processes. What matters is the number of rules and records, how often they change and the response time under a given load.

When it’s worth looking at Sylius

Sylius is developed as an e-commerce framework based on Symfony, that is, a foundation for building and customising a commerce application. That is how its maker describes the project. It is worth considering in an implementation analysis when non-standard logic is a permanent part of the business and will keep evolving.

One example is a customer organisation with many accounts, branch budgets and several levels of approval. Another might be a cart that turns into a quote, which is then negotiated and approved. In such a project you need to describe the process states, the permissions and the events that change them. A clear model of these rules makes it easier to assess future changes.

This doesn’t mean that all B2B features are available out of the box in the free edition. The Sylius Plus offer includes commercial extensions, including the B2B Suite and request-for-quote handling. The quote has to show what comes from the base, what from the paid package and what will be written. Features and licence terms need to be confirmed for the chosen option.

More freedom also means more decisions on the team’s side. You need to plan content management, integrations, the staff interface and deployments. Don’t compare a standard PrestaShop installation with an unlimited set of possibilities that have yet to be built in Sylius. Compare two ready-to-deliver proposals with the same scope.

ERP integration: where the final price is set

First choose the source of truth for product, stock, price and credit limit. It doesn’t have to be the same system for every kind of data, but responsibility must be unambiguous. If the ERP sets the trade terms, the store shouldn’t quietly add competing rules that the sales department can’t explain afterwards.

Decide how things should behave when the integration is unavailable. Can the last known price be shown? How long is it valid? Can an order be accepted, or only an enquiry? What will the customer see if the limit changed between opening the cart and confirming it? The answers should go into the requirements and the tests for both options.

Also check retries. If the connection drops after the order has been saved in the ERP, a retry shouldn’t create a second document. You need identifiers, logs and a way of reconciling state. A ready-made integration module is worth judging on precisely these situations, not just on successfully sending a single product.

Costs that only show up during development

Compare the cost of launch and the following three years. Include licences, hosting, maintenance, updates, monitoring and planned changes. Add the time of employees handling exceptions manually. If one option doesn’t support a needed process, its lower quote doesn’t yet describe the cost of running the business.

In PrestaShop part of the work may come down to configuring and adapting modules. In Sylius custom code or commercial packages may play a bigger role. That doesn’t mean there is a fixed price difference for every project. Check specific offers, the scope of testing and the availability of people who will maintain the implementation.

Ask for a quote for two changes you expect after launch. It might be a new type of discount and a second stage of order approval. The point isn’t a guaranteed price for many years, but checking which areas will need rebuilding. An architecture that works well for the first launch may turn out to be difficult for the planned direction of development.

Take into account the project being taken over by another team. Documentation, readable code, tests of the rules and repeatable deployment are valuable on both platforms. The popularity of a technology alone doesn’t provide a replacement if all the knowledge about prices and integrations sits with one person.

Does B2B need headless

Headless means separating the layer the customer uses from the system that handles commerce. It can make sense when the same processes have to feed several interfaces or when front-end development needs a high degree of independence. The need should, however, be described by a specific use case.

A separate front end adds areas to maintain: login, session, cart, error handling, analytics and interface compatibility. It doesn’t automatically speed up price calculation in the ERP. If the only justification is a modern look, also compare a solution without splitting the application. The graphic design doesn’t dictate the architecture.

A third option: improve the current store

When the problem is inconsistent rules or a slow import, start by putting them in order. A migration won’t decide for the company which price list applies and who approves exceptions. First describe the process, remove the contradictions and check whether the current platform really is the obstacle.

You can also extract a selected area, for example price calculation, without replacing the whole store at once. This approach needs its own analysis of availability and data consistency, but it lets you separate a specific problem from a full migration. Compare its cost with cleaning up the modules and with changing platforms.

How to run the comparison

1. Write down the purchasing processes, customer roles and trade rules.
2. Separate the requirements that are mandatory at launch from later development.
3. Prepare sample data and orders that show the difficult cases.
4. Get quotes for both options against the same list of requirements.
5. Check a prototype of the riskiest process.
6. Compare maintenance costs, limitations and the ability to change contractors.

For each requirement, note how it will be delivered and what hasn’t been checked yet. Such a table shows the risk far more clearly than a long list of “yes” marks next to features. To assess the answers, use the guide on how to read an e-commerce agency’s offer.

Frequently asked questions

Is Sylius more expensive to maintain?

That can’t be settled without the project scope. Custom code and licences generate costs, but so does maintaining many conflicting modifications. Compare specific processes and the development plan.

Can PrestaShop handle individual prices for hundreds of business customers?

The number of customers alone doesn’t rule this platform out. Check how prices are stored, the data volume and how often it is updated. You need a test of imports and purchases on a representative catalogue.

What about ERP integration on both platforms?

Assess the ready-made connection or the scope of building your own. What matters most are the data supported, errors, retries and responsibility for maintenance. The platform’s name doesn’t replace these arrangements.

Is headless necessary for B2B?

It isn’t a condition for selling to businesses. It is worth considering when there is a justified need for separate interfaces and independent development. In other cases it may increase the scope without solving the main problem.

If the decision depends on a few non-standard rules, start by describing them and building a prototype. As part of e-commerce consulting you can compare the options before a full implementation begins.

Artykuł PrestaShop vs Sylius for B2B sales pochodzi z serwisu eCommerce Expert.

Start with the work the store has to do

Comparing platforms only makes sense once sales have been described. A store with a few hundred products may have a complex configurator, while a catalogue of thousands of items may rely on a simple single-item purchase. In the first case the difficulty lies in the product logic, in the second perhaps in data import and search. The label “small store” hides these differences.

Prepare examples of real orders and show what happens to them after purchase. Who enters the product? Where does the stock level come from? Where is the invoice created? What does customer service do when a customer changes their address or orders an item that isn’t immediately available? The platform should fit these answers, not just the look of the site.

• Are how-to content and campaign pages an important part of daily work?
• What types of products, variants and pricing rules does the catalogue have?
• Which systems must the store exchange data with, and how quickly?
• Who will deploy updates and fix failures?
• What budget can the company allocate to maintenance after launch?

On that basis, choose a few scenarios to demonstrate. Ask contractors for both options to show the same process on similar data. That tells you far more about how useful a solution is than comparing feature lists on vendors’ websites.

Catalogue and product variants

Both platforms support products with variants. In practice you need to check how it is to work with your particular catalogue: how many combinations there are, how prices change, where images live and how stock is updated. For the team managing the product range, the time needed to correct a whole group of products may matter more than the mere existence of a feature.

WooCommerce provides a built-in CSV product import and export, including variable products. The scope and format of the data are described in the importer documentation. This is useful for a standard catalogue, but it doesn’t mean the fields of every additional extension are handled automatically. If a product has configuration saved by a plugin, check it separately.

Don’t accept an arbitrary threshold beyond which WooCommerce stops working and PrestaShop becomes mandatory. Performance also depends on database queries, filters, extension code, caching and infrastructure. Run a trial on representative data, covering search, filtering and import under traffic. An empty installation with a few products won’t answer questions about the target store.

Cost: implementation, extensions and maintenance

When comparing options based on open-source software, the price of the platform itself is just one item. Put analysis, theme, configuration, integrations, data migration, testing and training into the budget. Separately count hosting, updates, backups, paid extensions and support time. If you are considering a managed or subscription offer, check exactly what its price covers.

The same feature name can hide a very different scope. “Warehouse integration” can mean a manual file export or two-way synchronisation with error handling. A quote for a ready-made plugin isn’t comparable with building such a process from scratch. In both offers, ask for a description of update frequency, responsibility for failures and behaviour when the other system is unavailable.

Prepare a three-year cost: launch, expected licence renewals, maintenance and agreed development work. Add the time of employees doing manual tasks that a given option doesn’t automate. A cheap start can be a good choice if the scope is simple. It should, however, come from a deliberate limitation of features, not from leaving out the cost of running the store later.

B2B sales and price lists

“Supports B2B” needs clarifying. A discount for a customer group, a price agreed for a specific account, a credit limit and an order approved by a manager are different features. Write them down separately. For each, state whether it will be handled by the platform, an extension, custom code or the ERP.

First establish where the final price is created. If the ERP calculates individual terms, the store should receive an unambiguous result or apply agreed rules. Calculating discounts in parallel in several modules makes control difficult. A test covering a product on promotion, a customer discount and a quantity threshold will show more than a demo of a single price list.

Also ask for a demonstration of a change in trade terms. Check when the new price appears in the catalogue, what happens to an open cart and how the order is saved. If the purchase process involves multiple roles, negotiation or non-standard approval rules, broaden the analysis. Such a case is covered in the comparison of PrestaShop and Sylius for B2B.

Maintenance and updates

With WooCommerce you also maintain WordPress, the theme and the site’s other plugins. With PrestaShop the dependencies include the core, the theme, modules and custom modifications. In both cases what matters is the compatibility of the whole set. It isn’t enough that a single extension is on its latest version if that update doesn’t work with the rest of the store.

Agree the way of working when you choose the platform: a test environment, an update schedule, a test order and a rollback procedure. Check whether backups are stored off the server itself and whether someone can restore them. These tasks need to be included in the offer, even if the store looks trouble-free on launch day.

The ability to change contractors also matters. Your own service accounts, repository access and integration documentation make it easier to take over the project. The availability of many specialists for a given platform won’t help if nobody receives the sources of the modified theme or a description of the deployment process.

Which option fits your company

If you have a substantial WordPress site, regularly publish guides and want to add standard sales, WooCommerce should be on your shortlist. One admin panel can simplify the editorial team’s work. The condition is checking whether the current theme and plugins are also suitable for running a store.

If you are building a site primarily around commerce and the team works daily with products, deliveries and orders, test PrestaShop on your own scenarios. Assess the availability of the specific integrations and how convenient the admin panel is for staff. A platform’s intended purpose doesn’t replace a demonstration of the features you need.

For standard sales and no one responsible for technical maintenance, it is worth comparing SaaS too. A subscription can simplify some duties, but you need to check integration limits, data export options and the total fees. If the company has a very unusual process, comparing only two popular platforms may, on the other hand, narrow the choice too much.

A table for comparing offers

Frequently asked questions

Can a store be moved from WooCommerce to PrestaShop?

Yes, but the migration requires mapping data, features and URLs. A product import doesn’t automatically move the whole store. The detailed scope is described in the article on migrating from WooCommerce to PrestaShop.

Which platform is faster?

Without measuring a specific implementation there is no honest answer. Compare the same scenarios, data size and load. A home page test result isn’t enough to assess filters and the cart.

What about the cost of plugins and modules over longer-term maintenance?

Collect the renewal terms, scope of support and update costs for each paid add-on. Add the work needed when changing supplier or losing compatibility. The bill for the first purchase doesn’t show the whole cost.

Does the choice of platform affect SEO?

It affects how changes are implemented, but it doesn’t replace good content and correct configuration. In both options check URLs, indexing, speed and the ability to edit metadata. When changing platforms, existing URLs need a dedicated plan.

If both offers look similar, commission a demonstration of the hardest process on your own data. The result of that trial can settle the choice before a bigger spend. E-commerce consulting will help you put the requirements in order.

Artykuł PrestaShop vs WooCommerce: which platform to choose pochodzi z serwisu eCommerce Expert.

The PrestaShop store had three B2B price list modules, bought at different times from different vendors. Each implemented part of the pricing rules but ignored what the others did. The price in the cart could differ from the amount on the invoice. Explaining a single discrepancy took a salesperson half a day.

Analysis before buying another module

The client wanted a quote for a fourth module that would combine the three existing ones. I proposed two weeks of diagnosis first. The description of the problem suggested that the whole way prices were calculated needed to be examined.

The analysis showed that the price depended on four variables: the customer, the product, previous purchases and the account balance. The modules applied these rules independently, working around the limitations of the store’s data model. Combining them did not produce a consistent result.

Comparing three solutions

I prepared three options with their cost, risk and expected payback period:

• A fourth module meant the smallest outlay, but I estimated its useful life at about a year.
• Rewriting the pricing rules inside PrestaShop required a bigger investment and maintaining a custom workaround of the architecture.
• A separate pricing service followed by a platform change was the most expensive, but it removed the source of the discrepancies.

We added the annual cost of salespeople’s time and held-up orders to the comparison. It exceeded the difference between the options. Once that amount was taken into account, the client decided to extract pricing and migrate later.

Prices first, then the whole store

In the first stage I moved price calculation into a service with an API. The existing store fetched the result over HTTP. This stage took eight weeks and solved the most urgent problem while keeping sales running.

Ultimately the store was moved to Sylius, where the pricing rules could be described directly in the domain model. The implementation took another five months. The switchover happened after six months of history showing the pricing service running without discrepancies.

Results after a year

• The number of differences between the cart price and the invoice fell from a dozen or so a month to zero.
• Adding a discount rule took one day instead of two or three weeks of waiting for the module vendor.
• File-based orders were handled directly by the store, without an external module.
• Tests covered 94% of the pricing logic, whose errors directly affected billing.

Why this scope was justified

The decision came down to the scale of the problem and the cost of dealing with it every day. With thirty customers I would have recommended staying on PrestaShop and cleaning up the modules. With 380, the cost comparison justified the change. A migration is worth considering once you have checked whether a cheaper solution would achieve the goal.

Artykuł B2B price lists for 380 customers: changing how prices are calculated pochodzi z serwisu eCommerce Expert.