Taking over an abandoned ecommerce project: what we check first

Ecommerce projects get left behind for ordinary reasons. An agency closes or changes focus, a freelancer takes a full-time job, an internal developer leaves, or a relationship ends over budget or timescales. The business is left with a live store that takes orders every day, and very little idea of how it is put together.

When we take on a project like this, the first week is not about new features or opinions on the previous work. It is about finding out what exists, what could go wrong, and what needs doing first. This is the checklist we work through.

Access and ownership

Before anything else, establish who controls the parts of the business that the store depends on. It is surprisingly common to find critical accounts registered to a former developer’s personal email address.

• Domains. Which registrar holds each domain, whose account it is in, and when it renews. A lapsed domain takes the whole store offline and can be difficult to recover.
• DNS. Where DNS is managed, which may be a different provider from the registrar, and who can change it.
• Hosting and servers. Who pays for the hosting, who has administrative access, and whether there are servers or services nobody has mentioned, such as a separate staging server or a database host.
• Code repositories. Whether the code is in a repository at all, who owns that repository, and whether it matches what is actually running in production.
• Platform, app and plugin accounts. The store platform account itself, paid plugin licences, app subscriptions, theme licences and developer accounts. Licences tied to someone else’s account can stop receiving updates.
• Payment gateway and other services. Payment provider, email delivery service, search, reviews, analytics and tag management. Confirm the business owns these accounts and that API keys are known.

The aim is for every account to be owned by the business, with access granted to named individuals, and a list of what exists and where. If a former developer still has access, plan to remove it once you are confident nothing depends on their credentials.

Backups and security exposure

Backups

Do not assume backups exist because a hosting plan mentions them. Check what is backed up – files, database, uploaded media – how often, where the copies are stored, and how long they are kept. Then restore one to a separate environment. A backup that has never been restored is an assumption, not a backup. Take a fresh, independent copy of the code and database early on, before making any changes.

Security exposure

A project without an active maintainer often has unpatched software and accumulated access. In the first week we look for:

• Administrator accounts belonging to people who no longer work with the business, and shared logins.
• Outdated platform, plugin or extension versions with published vulnerabilities.
• Files that should not be publicly reachable, such as database dumps, backup archives, .env files or version control directories in the web root.
• API keys and passwords stored in code, and whether they may have been exposed.
• Unexpected files, scheduled tasks or admin users that could indicate an earlier compromise.

If there is any sign the site has been compromised, that changes the priorities immediately: preserve evidence, contain the problem and plan credential rotation before doing anything else.

How the store is built and deployed

What is customised and undocumented

Most stores have more customisation than anyone remembers. Compare the installed code against the standard platform and the original versions of themes and plugins to find what has been changed. Look for edited core or vendor files, custom modules, theme functions that contain business logic, and configuration that only exists in the production database. Write down what each customisation appears to do, even if the notes are rough.

Deployment process

Find out how changes have reached the live site. It might be a proper pipeline from a repository, a script on someone’s laptop, or files uploaded directly to the server. Check whether there is a staging environment and whether it resembles production. Until there is a safe, repeatable way to deploy and roll back, every change is riskier than it needs to be.

Dependency and platform versions

List the versions of everything: the ecommerce platform, PHP or Node.js runtime, database server, web server, themes, plugins, extensions and code libraries. Note which are past end of support, and which updates are likely to be difficult because of customisations or abandoned dependencies. On hosted platforms such as Shopify, look for deprecated API versions used by custom apps and themes relying on features that have since changed.

What is happening in production

Error logs

Application logs, web server logs, payment gateway logs and the platform’s own error reporting usually reveal problems the business has learned to live with: failing scheduled tasks, repeated database errors, checkout errors affecting some customers, or emails that never send. Look for patterns over several days, not just the most recent entries.

Integrations and scheduled jobs

Map every system the store exchanges data with – ERP, warehouse, accounting, marketplaces, feeds, email marketing – and how each connection works. Then find every scheduled job: server cron entries, platform scheduled tasks, and jobs that live on another server entirely. For each one, find out what it does, when it last succeeded and what happens if it fails. Integrations that quietly stopped months ago are more common than you might expect.

Stabilise first, then plan the longer fixes

By the end of the first week there is usually a long list. It helps to split it clearly.

1. Immediate stabilisation. Things that could cause lost orders, data loss or a security incident soon: missing backups, domains close to expiry, access held by the wrong people, known vulnerabilities, a failing order export. These are handled first, and usually quickly.
2. Short-term safety work. Putting the code under version control, creating a working staging environment, setting up a reliable deployment process and adding basic monitoring and alerting.
3. Longer fixes. Platform upgrades, rewriting fragile customisations, rebuilding problem integrations and reducing technical debt. These need planning and scheduling around trading periods, not rushing.

Resist the temptation to start rewriting in the first week. Without a clear understanding of the current system, well-intentioned changes can break things that were working for reasons nobody documented.

Communicating risk to the business

The people who own the store need to understand what was found without being alarmed by jargon or reassured by vagueness. We find it works best to describe each issue in terms of what could happen, how likely it is and what it would take to address: “The domain renews in three weeks and is registered to a personal account; if it lapses, the store goes offline. Transferring it is a small task and should happen this week.”

It is also worth being fair about the previous work. Missing documentation and shortcuts are often the product of tight budgets, changing priorities and handovers that never happened, rather than carelessness. The goal is a clear picture of where things stand, not blame, and a calm tone helps the business make good decisions.

If you have inherited a store with no active developer, or your current arrangement has ended and you are not sure what you are left with, a rescue assessment is a practical place to start. We work through this checklist with you, stabilise anything urgent, and give you a prioritised view of what needs doing next.