When your contractor stops responding, first secure access, data and the continuity of sales. Don’t start by ordering a new store. Taking over a store from an agency requires establishing what the company actually controls, making a backup and assessing the code and integrations. Only then can you decide what to keep, what to fix and whether a bigger rebuild is needed.
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.