What version 9 changes

Moving from 8 to 9 also affects the technologies the store runs on. PrestaShop 9.0 moved from Symfony 4.4 to Symfony 6.4. This change matters mainly to module authors and to people maintaining custom modifications. Code that uses older mechanisms may need adapting, even if the feature is meant to look identical to the customer. The scope of the changes is described in the PrestaShop 9.0 change documentation.

Check the server requirements for the specific release you plan to deploy. “Our hosting supports PrestaShop” is too general. You need a compatible PHP version, the right extensions, a database and enough resources to run imports and background tasks. The reference point is the official requirements table. Check separately the PHP serving the site and the PHP run by the task scheduler.

For a store owner, what matters is the result: being able to keep maintaining the system, the availability of the extensions you need and your sales processes working. Don’t assume the upgrade will by itself speed up the catalogue, fix search or simplify warehouse work. Such effects need a separate diagnosis and measurements before and after the change.

The biggest unknowns are often modules and the theme

In a standard installation, the scope of work is relatively easy to estimate. In a store developed over several years, the list of modules doesn’t yet tell you what really needs to be carried over. A payment module may have received a local patch, the theme may use a modified cart, and the ERP integration may reach straight into the database. Each such element has to be identified before quoting.

A vendor’s compatibility statement is a good start, but it applies to a specific version of their product. Check whether your licence covers access to that release and whether the update will keep your configuration. If someone has changed a module’s files, downloading a new package may wipe out those modifications. Custom code has to be compared with the original to decide which differences are still needed.

The theme needs a trial too. The home page may look fine while choosing a product combination, address validation or mobile payment stops working. With a bespoke theme you need the sources and instructions for building the files. With a ready-made theme, what matters is the availability of updates and the compatibility of the add-ons bundled with it.

How to check where you stand

Before discussing a date, prepare an inventory. For each extension, record its name, version, vendor, business function and the person responsible for maintaining it. Add information about the licence and any changes. A module nobody can describe needs checking: it may be redundant, but it may also be sending orders to the warehouse once a day.

• Establish the exact version of the store, PHP, database and theme.
• Collect a list of active modules, scheduled tasks and connections to external systems.
• Check overrides and direct changes to core files.
• Verify access to the code, backups and extension vendors’ accounts.
• Describe any unusual rules for prices, delivery, discounts and order handling.

The result should be a document that sorts elements into ready to move, needing a fix, needing a replacement or to be removed. For every unknown you need a way to resolve it. If the store has many overrides, a separate review of overrides in PrestaShop will help. Without this work, an “upgrade” may hide a rebuild of several important features.

When it’s worth postponing

Deploying just before your most important sales campaign increases the cost of any mistake. If there is no urgent security reason, it is wiser to prepare and test the change earlier and schedule the switchover outside the peak. A postponement should, however, have a specific date and conditions to be met by then.

The second reason is the incompatibility of a feature essential to sales. If the payment provider or the integration passing orders to the ERP doesn’t work, running the store on a new core achieves little. First you need a fix, a replacement or an agreed interim procedure. Don’t assume the vendor will be ready in time until you have a version you can test.

It is also worth combining work if the company is already preparing a theme change or a migration to another platform. Adapting a part that is about to be removed can be an unnecessary cost. The condition for such a decision is being able to keep the current store safely maintained until the next implementation.

When delay makes the store harder to maintain

Postponing an upgrade doesn’t stop other suppliers from changing. The host updates the environment, the payment provider changes its integration and the module vendor releases new versions. If the store needs more and more exceptions, every new feature first has to be adapted to old limitations. That effort should appear in the cost comparison.

Check the current support status of the release you use and its dependencies. The availability of security patches doesn’t follow from the store still taking orders. When a security issue appears, the decision on timing has to be based on its significance for the installation and the available safeguards, not only on the campaign calendar.

Compare two options over the same period: cleaning up and upgrading now, versus continued maintenance with a later move. In the second option, include compatibility fixes, extra testing and work that will have to be done again later. Such a comparison gives a better basis for a decision than the belief that a working store should never be touched.

How to prepare a safe upgrade

Start with a backup of the files and database, and a test restore. Then set up a separate test environment. Block access for outsiders and indexing, disable emails to customers, and switch payments and integrations to the appropriate test mode. A copy of production must not accidentally create real shipments or pass on duplicate orders.

On the copy, run the full upgrade and write down every extra step. Test the processes: guest and logged-in purchase, product combinations, discounts, delivery, payments, provider confirmations, emails and export to the ERP. Also check order cancellation and refunds. Ask a customer service employee to do their usual tasks, because not every exception is visible in the documentation.

Before the switchover, decide when writes will be paused, a fresh backup made and the new version launched. Agree who decides on a rollback and how payments coming in during that time will be reconciled. Returning to the old database after accepting new orders requires those orders to be secured and the data reconciled. Restoring the files alone doesn’t solve that problem.

Before approving the deployment, it is also worth agreeing how it will be signed off. Prepare a table with the test name, expected result, the person checking it and its status. If a case failed, describe its impact on sales. A minor visual difference and incorrect price calculation should not carry the same weight. Make the go-live decision based on this list, not on the tool’s message that the upgrade finished without errors. Keep the trial results with the project documentation so the next contractor knows what was actually verified and which limitations the company accepted.

Frequently asked questions

Can the store be upgraded without downtime?

Most of the preparation can be done while sales continue as normal. The switchover itself may require briefly pausing orders to keep the data consistent. A promise of zero downtime requires a specific technical solution and a rehearsal of the whole procedure.

What about modules the vendor no longer develops?

First check whether their function is still needed. If it is, you need to find a replacement or commission an adaptation of the code, taking the licence into account. In both cases, agree who will be responsible for fixes later.

Will the upgrade affect my Google rankings?

The version number itself guarantees neither an improvement nor a drop in visibility. Check URLs, content, canonical links, indexing and server responses before and after deployment. If you are also changing the URL structure, you need a separate redirect plan.

How long does a major version upgrade take?

The time depends mainly on the compatibility of extensions, the amount of custom code and the number of processes to test. A reliable date comes after the inventory and a trial on a copy. The time it takes to run the upgrade tool is only part of the work.

Where to start the decision

Ask your contractor for a list of obstacles, a test plan and a switchover procedure. Only on that basis should you approve the budget and the date. If you need help defining the scope, see store migrations and upgrades.

Artykuł PrestaShop 8 or 9: when to upgrade and when to wait pochodzi z serwisu eCommerce Expert.

Before you change anything

Establish the scope of the failure. Does no page open at all, only the admin panel, or a specific checkout step? Check one example without logging in and another on a test account. Note the product used, the delivery method and the action that preceded the error. If the problem concerns payments, don’t repeat purchases blindly: first check whether the provider has already taken the money.

Write down recent changes. A module update, a PHP switch, a theme deployment, a product import and a change of hosting settings are all different leads. The time of the report doesn’t have to be the time the failure started. Compare it with the last successful orders and the logs, so you don’t blame the problem on a change made after it had already appeared.

Before intervening, make a backup of the database and files or ask your host to secure the current state. Don’t overwrite the last working backup. The database from the time of the failure may contain orders and payments that aren’t in yesterday’s backup. If disk space is short, creating a large archive on the same server may make things worse. In that case agree another way of making the backup with the administrator.

Where to look for logs

You may need the web server, PHP and application logs. On shared hosting, start with the logs section of the control panel. If you don’t have access to them, give support the exact URL, the time including the time zone and a description of what you did. A request saying “the store doesn’t work” leaves far more room for guesswork.

On a VPS the location depends on the Apache or nginx configuration, PHP-FPM and how the store is run. In a container environment some logs may go to the process output rather than a separate file. In a PrestaShop installation, also check the application log directory, usually within var/logs, depending on the version and configuration. No entry in one place doesn’t mean there was no error.

Look for the event that matches the time of the attempt. Read the first relevant exception and its surroundings, not just the last line. A missing class message may result from an incomplete deployment, and a database connection error from the database being unavailable. Keep the original excerpt for analysis. Before sharing it outside the authorised team, remove passwords, tokens and customer data.

Debug mode: how to use it

If the admin panel works, debug mode can be enabled in the performance settings under advanced parameters. Without access to the panel, the PrestaShop documentation describes changing the _PS_MODE_DEV_ constant in config/defines.inc.php. Change the existing definition instead of adding a second one. The configuration is described in the official debugging guide.

Do this on a secured copy or in an environment with restricted access. A detailed message can reveal paths, queries and configuration details. Debug mode isn’t a fix: it helps you see the cause. Once you have recorded the data you need, turn it off and check how the store behaves in normal mode.

If the error occurs before PHP or the application starts, PrestaShop’s debug mode won’t show anything. In that case you need to go back to the server logs and the hosting configuration. Don’t keep piling up changes just because you still see the same generic message on screen.

How to tell common causes apart

PHP out of memory

A message containing Allowed memory size exhausted indicates that the process exceeded its memory limit. Find out which action caused it. Importing a large file and an infinite loop in a module need different solutions. Raising the limit may be justified, but only after checking usage and the server’s available resources.

Incompatible PHP version or extension

If the failure started after an environment change, compare the PHP version with the requirements of the exact release of the store and its modules. A syntax error, a missing function or an incompatible method declaration are clues for further analysis. Restoring the previous configuration can help isolate the change, but ultimately you need a supported and compatible combination of software.

A module, an override or an incomplete deployment

A path to an extension in the stack trace shows where the error occurred, but not always its source. Check that the files and dependencies are complete and what changed last. When the message concerns an overridden method, look at the overrides. Simply copying a missing file from a random version can introduce another incompatibility.

Cache and permissions

An error writing or creating a file may result from the wrong directory owner after a deployment. Check the PHP process user and the required permissions. Don’t set 777 across the whole store. If stale cache files are the cause, rebuild them according to the procedure for your version, after keeping the logs needed for the diagnosis.

No disk space or an unavailable database

Check disk space and the file count limit. A full disk can prevent writing sessions, cache and logs, so the absence of a new message can itself be a symptom. For database connection errors, verify its availability and connection limits. Don’t run table repairs or change login credentials without confirming the cause.

When the error appeared after an update

Stop further deployments and compare the state before the change with the current one. Check the package version, whether the files are complete and whether the update changed the database. Rolling back only the code may not be enough if the new version transformed the data. The rollback plan has to cover both.

If the logs point to one module, disable it in a controlled way and repeat exactly the same test. In versions that provide the relevant command, you can use the PrestaShop console; check the syntax in the help of the installed release. If the application cannot start, the console may not work either. Then you need to analyse the files, dependencies and module registration.

Renaming a module’s directory isn’t a universal equivalent of disabling it. It can leave references to classes and configuration behind. Don’t delete the module’s tables either: they may store data needed to settle orders. After the fix, check not only the page that returned the error but also a purchase, payment confirmation and handing the order over for fulfilment.

When to stop trying on your own

Hand the diagnosis over to a technical person when the problem concerns order data, a suspected breach, database corruption or an update you can’t safely roll back. Do the same if you have no working backup and each further step changes the production state. More random fixes make it harder to establish the cause later.

Prepare a short report: store and PHP versions, the scope of the failure, when it occurred, recent changes, an example URL and a log excerpt. Add what has already been done, even if it didn’t help. Share access through a secure channel, using a separate account with the scope needed for the work.

Once the cause is removed, write a short note: what stopped working, which message confirmed the diagnosis, what was changed and how the fix was checked. Include whether orders from the time of the failure need handling. Such a record will help with the next report and let you see whether the problem comes back. If the failure revealed missing monitoring of a particular payment or integration, add the appropriate check to the maintenance procedure.

Frequently asked questions

Does a 500 error mean data loss?

No. It tells you a request wasn’t handled successfully, not what state all the data is in. The operation may, however, have partly completed, so before retrying a payment or an import you need to check the result on both sides of the integration.

How do I disable a module without access to the admin panel?

If your version provides a working console command, use it after checking the help. When starting the application ends in an error, what to do depends on the cause. Don’t use a random SQL query found for a different release.

Why does the store work but the admin panel doesn’t?

The admin panel and the customer-facing part run different pieces of code. The failure may concern an admin module, a specific view or permissions. Check the logs for the attempt to open the panel separately.

Can I restore a backup myself?

Yes, if you know the procedure and which data will be replaced. First secure the current state and any orders created after the backup date. The files, the database and any environment changes must match each other.

The most useful first step is to find the specific error in the log and link it to an action in the store. If you need support with the diagnosis, use troubleshooting help and include the information you have prepared.

Artykuł 500 error in PrestaShop: how to find the cause pochodzi z serwisu eCommerce Expert.

What an override actually is

This article is about overriding classes and controllers, not about changing the look of a template. This mechanism lets you replace or extend a piece of PrestaShop’s standard logic. From a store owner’s point of view it means that some operations may work differently than in a clean installation: for example price calculation or the condition that makes a delivery method available.

A hook is an extension point that a module attaches its own behaviour to. An override reaches into existing behaviour more directly. A module, in turn, is a way of delivering a feature and can use various mechanisms, including overrides. So the statement “we did everything in a module” doesn’t answer the question of how deep the intervention goes.

The PrestaShop documentation points out the limitations and the risk of conflicts between overrides, and describes alternative ways of extending the system. The choice depends on the place in the code and the mechanisms available in a given version. The reference point is the official description of overrides. The practical conclusion: before overriding, check whether the same goal can be achieved through a provided extension point.

Why an update can expose the problem

Imagine a modification that takes over the calculation of the delivery fee. It was created for a specific version of the store and uses its arguments and the way it processes data. After an update, the core may pass different data, expect a different type of result or run an extra check earlier. The custom code still assumes the old flow.

This doesn’t always mean a blank page. The store may keep taking orders but calculate a discount differently for a selected group or skip a condition for a particular delivery method. The error only shows up with a specific cart. That is why a test that consists of opening the home page isn’t enough to confirm compatibility.

Copying an entire core method and adding a small change to it needs particular attention. Such a solution may also preserve old logic that the project later fixed. When updating, you have to compare not only what was added but also what changed in the original. The bigger the copy, the more behaviour has to be reassessed.

When an override may be justified

Sometimes the feature you need concerns a place for which the given version provides no suitable extension point. A limited override can then be a sensible choice if the alternative requires a much larger rebuild. This decision must, however, be documented and taken into account in later maintenance. The cost doesn’t end on launch day.

The documentation should include the reason for the change, the supported versions, the code owner and examples of the expected behaviour. You also need information about the alternatives considered. “The client needed a different price” is not enough. “For a customer with contract A, when ordering a full pack, the ERP price applies” lets you prepare a test.

Agree on the condition for removing the override. It may be the arrival of a suitable hook, a module replacement or dropping the feature. Without such a review, temporary code stays for years. Each next person treats it as essential because nobody is sure what will happen once it is switched off.

How to check what is in your store

The review covers the override directory, module code and a comparison of core files with the original release. Directly editing a core file is a separate kind of modification; it doesn’t have to appear on the list of overrides. That is why an empty overrides directory is no proof that the store is still standard.

Ask the developer for a summary that is also understandable to the person responsible for sales. For each change you should be able to see the business function, the place in the code, the source and how to verify it. A class name on its own won’t help you decide whether the modification can be dropped at the next update.

• Which customer or staff action does this piece change?
• Does it come from a module, or was it written for this store?
• Is it used, and on what data can that be confirmed?
• Does another add-on interfere with the same area?
• Which tests will show that the feature works after the update?

Compare against exactly the release that is installed, not any PrestaShop package. Generated files, configuration and store data need separate treatment. When taking over a project, the repository history and older deployment packages help. If they are missing, you need to state clearly which findings could not be confirmed.

How to clean up existing modifications

The first step is to establish the current behaviour. Record sample carts, prices and delivery conditions before changing any code. For rules that affect billing, prepare expected results agreed with the person responsible for sales. An automated test without the correct business answer may only lock in the existing error.

Next, check which features are still needed. Some may have been replaced by a new version of the platform or a module. Others may concern an unused delivery method or a finished promotion. Removing an unnecessary modification can be simpler than rewriting it, but it also requires a trial on a copy and a dependency check.

For the remaining changes, choose how to implement them: an available hook, a service, decoration where the architecture allows it, or a still-maintained override. Moving code to another file isn’t enough if it keeps the same assumptions about the core’s internals. The goal is to reduce dependencies and make testing easier.

Work in stages. First reproduce the behaviour of one feature, compare the results and only then move on. Replacing price lists, the cart and integrations all at once makes it hard to find the source of differences. If the store update is urgent, separate the necessary adaptation from larger clean-up work that can wait for a separate date.

How to test a change before deployment

Test the edge cases, not just the simplest purchase. If the modification concerns a discount, include a reduced product, several items, different customer groups and changing the quantity in the cart. For delivery, check the free shipping threshold, products with different restrictions and changing the address. The list should follow from the rule that was actually changed.

Also compare the saved data: the order total, the values passed to the payment provider and the document sent to the ERP. A correct amount displayed on the page doesn’t guarantee that every system received the same. Record the results together with the code version so the test can be repeated later.

After deployment, watch the area affected by the change. Agree which discrepancies need an immediate response and who checks them. If a 500 error occurs, keep the log and the test data. With a silent pricing error, value comparisons will matter more than monitoring page availability.

How not to be back here in a year

Write into the terms of cooperation an obligation to document core changes and overrides at every acceptance. A change should come with sources, a rationale and a test. Repository access lets you check what was actually deployed, but on its own it doesn’t replace code review.

At the next update, go back to the register of modifications. Check whether the new release offers a simpler solution and whether the feature still has an owner on the business side. Keeping a short, up-to-date list of dependencies is cheaper than reconstructing them during an outage.

Hand this register over together with the code whenever you change contractors and when planning a store update.

Frequently asked questions

Is an override always a mistake?

No. It can address a need for which there is no suitable extension mechanism. It must, however, be a deliberate decision with documentation and a maintenance plan.

How can I tell whether the store has core changes?

Compare its code with the original package of the same release and the deployment history. The admin panel alone won’t show the full picture. Assessing the differences is best left to someone who knows the project structure.

How much does it cost to clean up overrides?

The number of files isn’t a good basis for a quote. One price list change may take more work than several simple overrides. You need a description of the features, dependencies and test cases.

Does this affect the store’s security?

It can, if custom logic bypasses permission checks or validation, or preserves a piece of code that needed a fix. The mere existence of an override doesn’t prove a vulnerability. The specific implementation is what gets assessed.

Before a planned PrestaShop update, collect a list of changes and what they are for. If nobody knows what was overridden, start with a technical audit that translates the code into a scope of work and a risk to sales.

Artykuł Overrides in PrestaShop: why they break updates pochodzi z serwisu eCommerce Expert.

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.

The first 48 hours: access and a backup

Appoint one person to gather information and coordinate changes. If every employee separately asks for a password reset or changes settings, it is easy to lose track. Prepare a register of services: name, account owner, login URL, provider contact, renewal date and who has access. Don’t write passwords in a shared spreadsheet.

Check the domain and DNS, hosting, store admin, database, repository, email, payment providers, courier integrations and the ERP. Include analytics accounts, advertising tools and services that store backups. Store administrator access doesn’t mean server access, and being able to pay for hosting doesn’t necessarily mean control over the domain.

When recovering accounts, use the providers’ official procedures and documents confirming the company’s rights. First check the email addresses and phone numbers used for account recovery. Once the situation is under control, give the new team separate accounts. Plan password and key changes with the services that use them in mind, so you don’t accidentally stop a synchronisation.

Make a backup of the files and database before any bigger changes. Also secure the logs, the scheduled task configuration and the server settings needed to recreate the store. Don’t keep the archive in a public directory of the website. If you have no technical access, ask your host to secure the data within the rights you have.

What you have and what is missing

Separate the working version of the store from the materials needed to develop it. The server may hold PHP files but only built and minified JavaScript and CSS. The theme sources, tool configuration or deployment script may be missing. A server backup is valuable then, but it doesn’t replace a complete project.

Check the repository: does it contain the last deployed version, all custom modules and the change history? Access to an empty or long-outdated repository alone isn’t enough. A comparison with production will show whether fixes were made directly on the server and whether they can be reproduced.

• Collect the bespoke code, theme sources and build instructions.
• Find the list of licences, invoices and extension vendor accounts.
• Secure descriptions of the integrations, scheduled tasks and automated exports.
• Check whether there are instructions for deployment and restoring backups.
• Collect open tickets, accepted requirements and unfinished work.

Where something is missing, record the consequence. Missing module documentation may mean the code needs analysing. Missing sources for part of the interface may force it to be rebuilt. Lacking the right to download an add-on’s updates requires contacting the vendor. Such a description is more useful than a general verdict that the previous agency left a mess.

How to assess the state of the store

The new contractor should first run a copy in an isolated environment. Access has to be restricted, real email sending disabled and automations that create documents or shipments disconnected. Only on such a copy can you test updates and the effect of disabling suspicious modules.

The review covers the platform and PHP versions, extensions, core changes, permissions, backups and how deployments are done. In PrestaShop, overrides need separate attention. The technical list should be tied to sales: which part is responsible for prices, availability, payments and passing on orders.

Check the tasks that run in the background. The store may look fine even though it hasn’t updated stock for a week or isn’t receiving confirmations. For each integration, establish the direction of exchange, frequency, log location and who responds to errors. Pay attention to processes that have so far been run from the previous contractor’s infrastructure.

The takeover report should group the work by consequences: urgent threats to sales and data, necessary maintenance and later development. Each item needs evidence, a proposed outcome and an estimate with its uncertainty marked. The age of the store alone doesn’t justify building a new system.

Formal matters to clarify

Collect the contract, orders, acceptance reports, correspondence and licence documents. Check what was agreed about the code, access to sources, modifications and handover after the end of cooperation. Don’t draw conclusions about rights to the whole project solely from an invoice or from the fact that you use the store.

Third-party components have their own terms. A module bought by the agency may require an account transfer, a change of assigned domain or a new licence; this depends on the vendor’s rules and your arrangements with the contractor. Ask for confirmation for each specific product. A general assurance that “everything is paid for” doesn’t explain access to updates.

If there is a dispute over the code or a refusal to hand over materials, give a lawyer the documents and a precise list of what is missing. In Poland the basic rules are set out in the Copyright and Related Rights Act, but assessing rights requires taking the specific contract into account. Securing the store technically and pursuing claims are separate tasks.

Handing the database over to a new company also requires putting the rules for access to personal data in order. Verify roles, the data processing documentation and how the previous contractor’s access is ended with the person responsible for data protection. Agree what happens to working copies; the obligations related to ending services are covered in the Polish data protection authority’s (UODO) guidance on data processing. Don’t send the full database to several potential contractors just so they can compare quotes.

How to prepare the handover to the new team

Prepare a short document describing how the company and the store work. List the key processes, campaign dates and deployment constraints. Add a few examples of orders with unusual conditions. The person taking over the store needs to know what behaviour to preserve, not just how to run the application.

Organise the materials into four groups: code and deployments, services and access, business processes, and a list of problems. Hand over secrets separately in a password manager. Assign an owner to every access, and once the takeover is complete remove unnecessary permissions and unused keys.

Define a measurable end to the takeover stage. The new team should be able to recreate the store, carry out a controlled deployment, find failure logs and show how to contact the providers. It should also present a list of gaps that haven’t been resolved yet. A takeover doesn’t have to mean fixing all historical problems at once.

How to reduce dependence on the next contractor

Your own accounts and up-to-date documentation should be part of normal work, not a package prepared only when you part ways. Take delivery of the code and a description of changes after each stage. Check that the deployed version is in the repository and that it is known how to recreate it.

Appoint someone on the company side to be responsible for renewal dates and access. Agree on a regular backup restore test and on keeping the list of integrations up to date. Even a good contractor may change their team, end the service or be temporarily unavailable. The store should have a documented way of running in that situation too.

Before a new contract, use the list of questions for an e-commerce agency. Check the terms for handing over the project and handling failures after launch particularly carefully.

Also agree on a contact channel for the takeover period. Employees should know whom to report a missing order, a wrong price or broken shipping to, and what information to include. The new contractor needs a single list of reports with priorities. Without it, it is easy to focus on visible details while a serious integration problem stays buried in private correspondence. After the first review, agree together on the order of fixes and a date for reassessing the state of the store.

Frequently asked questions

The contractor won’t hand over access. What can I do?

Collect the documents, identify the missing accounts and use their providers’ official procedures. In parallel, clarify with a lawyer the obligations arising from the contract. Don’t try to access other people’s accounts outside the authorisation procedure.

Are the modules bought by the agency mine?

It depends on the licence, how they were bought and the contract. Check whether you can use them, update them and transfer their support to another contractor. You need confirmation for each specific extension.

Does the store have to be rebuilt from scratch?

No. First you need to assess whether it can be recreated, maintained and developed. A rebuild may be justified, but it should follow from a comparison of costs and limitations.

How long does taking over a store take?

It depends on access, documentation and the degree of modification. Separate securing current sales from fully understanding the project. The timeline for the second stage can be reliably set after the first review.

If you need help, prepare a list of access details, a description of current problems and information about the latest backup. It is a good starting point for taking over and stabilising the store.

Artykuł Store abandoned by its developer: where to start pochodzi z serwisu eCommerce Expert.

I come back to this project because it shows well how my work has changed. I know its scope and I remember what we spent our time on. So I can compare specific tasks with how I would approach them now.

A simple directory, a lot of work underneath

The PrestaShop experts directory is a catalogue of certified agencies. A store owner browses their profiles, checks their specialisations and references, and then contacts the chosen contractor. Agencies manage their profiles and take care of how they present themselves against the competition.

From a visitor’s point of view the principle is simple. When building it, though, every stage needs attention: data entry, validation, search and presentation of results. A filter selected on the page must match the parameters in the URL and the database query. A form should accept valid data and catch invalid data. Everything has to work across different language versions.

On top of that comes the admin panel. The directory’s users never see it, but building it took as much work as the public part. These are the tasks that filled week after week for us: necessary, often repetitive, and each one requiring code to be written and checked.

Three people also meant time spent on collaboration

Splitting the tasks let us work in parallel, but it required daily coordination. We waited for code reviews, agreed on solutions and merged changes made in different parts of the application. In the schedule this collaboration looked smaller than it later turned out to be in practice.

That is why three months of work by three people is much more than just writing features. That time also included everything needed to turn separate pieces into one working application.

What the work would look like today

Over recent months I have built myself a set of tools based on language models. I hand a large part of repetitive programming work over to them. For a directory like this I would start by describing the data structure and the rules of operation, and then use that to create the application skeleton, migrations and the admin panel.

These are tasks where today I think in days rather than weeks. The same goes for forms, validation and language versions: a shared description lets me generate related pieces that previously had to be written separately. My job then is to check whether the result matches the assumptions. Places where the solution departs from the typical pattern need particular attention.

The place of testing in the whole process has changed too. Tests used to be left until the end, if there was time, and there rarely was. Now they are written together with the code. I can move straight on to review without waiting for a second developer to finish their task.

Hence my estimate: one month of solo work instead of nine person-months. A large part of that earlier effort went into activities that tools now handle. Working alone also removes the time needed to coordinate three people.

What I account for in that month

I would still need to talk to the people who will use the directory. To agree what an agency profile contains, who can edit it and how search works. The country filter is a good example. Should it indicate where the agency is based, or the market it serves? Both options can be programmed. The choice depends on how a store owner looks for a contractor.

A model can suggest an answer, but without knowing users’ needs it is easy to make a wrong assumption. Writing code faster doesn’t relieve me of making that decision.

In the estimated month I also include reading and checking the generated code. It needs at least as much attention as code written by hand. A solution that looks finished can lull you into a false sense of security, and I am still the one responsible for how it works.

What this comparison says about project pricing

That month is my assessment of a specific project that I know. It shows how much the contractor’s way of working matters to the cost of an implementation. For years we mainly counted the time developers needed to write a solution. Today, for repetitive tasks, that effort can be much smaller.

If you are commissioning a similar panel, ask the contractor to explain what they will spend the quoted time on. How do they use AI? How much work do they plan for defining requirements, and how much for checking the result? You will learn more from that conversation than from the number of hours alone.

This comparison also led me to take a broader look at my profession and how implementations are billed. I write about it in the article AI is changing our world.

Artykuł The project we had three months for pochodzi z serwisu eCommerce Expert.

What had to be checked before the migration

Over the years 40 modules had been installed in the store. Seven had modified code, and three were no longer maintained by their makers. The environment ran on PHP 7.1 at the end of its support, which blocked further updates.

The client had previously talked to two agencies. Both proposed a new store and expected organic traffic to drop by around 40% in the first six months. With Google’s share of sales at that level, the loss would have been greater than the cost of the implementation.

Over a decade thousands of URLs had been created for categories, filters, manufacturers and campaigns. Some still brought in customers, even though the company no longer actively used those pages. They had to be found and accounted for in the new structure.

Inventory of URLs and modules

I spent the first two weeks on analysis, before writing any production code. I combined data from Search Console, the sitemaps and the server logs from the last twelve months. The list covered 11,800 unique URLs with at least one visit. For each one I defined a target page.

I also checked what each of the 40 modules did. 22 turned out to be unnecessary, including four that duplicated the same feature. This reduced the number of elements carried over to the new store.

Preparing the new version

For eleven weeks I prepared the store on PrestaShop 8.1 in a separate environment. I ran the migration script many times to find unusual cases in the data and check how they were handled. The last run before the switchover, on a fresh copy of production, took forty minutes.

The 301 redirect map covered all 11,800 URLs. An automated check after deployment verified the server responses, the number of redirect hops and the content of the target pages. It found 340 URLs leading to empty categories. I fixed them before submitting the new sitemap.

Results after the switchover

• The downtime needed to launch the new version was 22 minutes.
• The largest daily drop in organic traffic was 12% and occurred on the sixth day after the migration.
• After 17 days traffic returned to its pre-migration level.
• Category page generation time fell from 2.9 to 0.7 seconds.
• The store used 18 modules instead of the previous 40.

Why the preparation mattered

Understanding the old store took a large part of the work. The list of working features and URLs made it possible to plan the migration before implementation began. In this project it was precisely this preparation that helped limit the risk the earlier agencies had feared.

Artykuł Migrating a B2B wholesaler from PrestaShop 1.6 to 8 pochodzi z serwisu eCommerce Expert.

Why the manual test didn’t catch the error

I spent the first hour backing up the database and files, and the second comparing logs from three weeks. The problem affected one payment method, chosen by 78% of customers.

On Sunday night the payment module had updated itself automatically. The new version changed the format of the gateway’s response. The store didn’t recognise the confirmation and left the order with the status “awaiting payment”, even though the operator had taken the money.

The client had tested purchases using a traditional bank transfer. That method worked, so the test didn’t reveal the failure. The whole diagnosis took four hours.

The fix and handling orders in progress

Over the next two hours I added support for the new format while keeping compatibility with the old one. This let the store correctly process earlier orders as well. I recovered 214 orders that had been stuck for three days. Customers received a message, including those who had already bought the products in another store.

Why the report only came after three days

The store had monitoring for page availability, response time and disk space. It did not, however, track the number of orders. The site stayed available, so the working alerts didn’t signal any problem with sales.

I added an SMS alert comparing the number of orders over two hours with the average for the same time window over the previous four weeks. The alert fires when orders drop below 30% of that average. Setting up the monitoring took a day of work. The cost of three days of downtime was more than a hundred times higher.

What changed after the intervention

• The checkout process was working correctly six hours after the report.
• I recovered 214 orders held up by the payment error.
• Automatic module updates were replaced with a procedure for checking changes on a copy of the store.
• Monitoring now covers a drop in the number of orders, not just site availability.

Artykuł Payment failure after a module update pochodzi z serwisu eCommerce Expert.