Handing a project over to a new contractor: what to take while the old team still answers

Handing a project over to a new contractor is not sending someone a zip file. It is a transfer of ownership: access, knowledge, and the right to make decisions.

Most owners think about it at the last minute. The contract with the old team is over, the new team is waiting, and then it turns out only one person knew the hosting password. And that person is on vacation.

A caveat first. I have no data on how often handovers go wrong, and I won't invent any. What follows is the order in which I take over someone else's Bitrix project. It works for the store owner and for the incoming team.

Access first, code second

You can always pull the code off the server. A domain registered to your former contractor is a much slower and more awkward thing to get back.

So the first list is not about architecture. It is about who owns what:

  • the domain and DNS;
  • the hosting account or server, including root or sudo;
  • the repository, with admin rights;
  • the Bitrix license and the vendor account behind it;
  • payment gateway, shipping, SMS and email providers;
  • the 1C (ERP) exchange: credentials and who set it up;
  • analytics and search console accounts.

All of it should belong to your company. The old contractor can keep access during the transition, but should not be the owner. I made the same point in the piece on choosing an ecommerce contractor: when you own the code and the access, changing teams is unpleasant but doable.

Rotate the passwords once the handover is done. It's not about trust. You simply no longer know who has them.

Compare production with the repository

The repository shows the project as it was meant to be. Production shows the project as it is.

On older Bitrix projects these two drift apart more often than anyone likes. Someone patched a template directly on the server. Someone changed a module setting in the admin panel, which never lands in Git anyway.

What I do in the first days:

  • copy the files from production and diff them against the branch everyone calls main;
  • list everything that exists only on the server;
  • check which modules are installed and which ones are custom;
  • confirm there is a working database backup, and find out when anyone last restored it.

If Git turns out to lag behind production, that's fine. You just want to learn it before your first deploy, not after.

Find what nobody wrote down

The riskiest part of a handover is not the code. It's whatever runs in the background and nobody remembers until it breaks.

In a Bitrix project I look for:

  • server cron jobs and Bitrix agents: what runs and how often;
  • the 1C exchange: which direction, what schedule, who watches the errors;
  • product feeds for marketplaces and ads;
  • manual routines someone does every Monday and considers too obvious to mention.

You won't find the last one in the code. Only people can tell you about it.

Talk to the old team while they still answer

The window in which the previous contractor is willing to answer questions is short. Use all of it.

The questions I'd ask:

→ what is the most fragile part, and what were you afraid to touch; → which tasks were left unfinished; → which "temporary" fixes became permanent; → how a release actually ships: by hand, by script, through CI; → who on the business side signed off on changes.

How the conversation goes matters too. Calm, specific answers are a good sign. When a client can't explain why the previous contractor "disappeared," I get careful and offer a short discovery phase before any estimate. I explained why in the post on pricing a project by risk, not hours.

Write the answers down right away. Not in a chat thread, but in a document that stays with you. My own setup for keeping project knowledge between engagements is in the post on Claude Code and Obsidian.

Don't start with a rewrite

A new team almost always finds plenty to dislike in someone else's code. Sometimes they're right. But "let's rewrite it" in week one usually means nobody has understood the project yet.

Legacy Bitrix can be painful, but it sells. The new team's first job is not to break what works. The second is to find out where it actually hurts.

I start by watching: logs, errors, slow pages, complaints from the content team. What I check first is in What I Check in the First 15 Minutes on a Project That's Already on Fire.

Then I take one small piece of work. It shows how the team copes with this codebase while keeping the risk to the store low. More on that in the post about the first work slice.

And when a client arrives with "we're leaving our old contractor and rewriting everything while we're at it," I split those into two jobs. Changing teams is a transfer of ownership. A rewrite is a separate project with its own scope. I covered that in Rewrite is not a scope.

A short handover checklist

→ domain, hosting, repository, Bitrix license and third-party services are in your company's name; → passwords rotated after the handover; → production compared with the repo, differences written down; → a database backup exists and has been restored at least once; → cron jobs, agents, the 1C exchange and manual routines are found and listed; → the old team's answers live in a document you keep; → the new team's first task is small and stays away from checkout.

If you're switching contractors right now and aren't sure you've taken everything, send me a message. I'll look at your list and tell you what's missing.