Our company has hired an outside development company to design a new e-commerce site for us. Unfortunately, they have become unreliable taking days to respond to emails and never answering there phone and we are worried that they will not be helpful once the site goes live if we run into any problems.

I was put in charge of obtaining information and finding a second company to review the site and become the new developers, should something go wrong.

The problem/question I have is that I do not know what information I need to get from the first development company that would allow the new one to become familiar with the site enough to fix any crashes or bugs.

Can you guys help me come up with a list of things I will need to get this going?

Sorry if this is not posted in the right place. If it is not, can you please move it?

Dani AI

Generated

A concise, prioritized checklist and a short handover workflow that help a replacement developer reproduce, debug, and deploy a live e-commerce site.

  • Source code repository: VCS type, repo URL, read/write account for the new team, exact commit/tag deployed, submodules and private packages.
  • Build artifacts and assets: compiled bundles, CDN locations, and any stored release packages.
  • Deployment and CI: deploy scripts, full deployment commands, environment variables, CI/CD account access, and deploy keys.
  • Production database: engine/version, full backup/dump, schema migration scripts, and how restores are performed.
  • Hosting and server access: hosting provider account, server IPs, SSH keys or sudo accounts, OS and package list, and cron/scheduled jobs.
  • DNS and domain registrar: registrar login and current DNS records (zones, TTLs).
  • SSL/TLS and certificates: certificate files, private keys, CA chain, and renewal process.
  • Payment and third-party services: payment gateway/merchant account info, API keys, OAuth clients, SMTP, CDN, analytics, and licensing keys.
  • Config and secrets: config files, .env methods, secret-storage location (vault), and a map of critical environment variables.
  • Dependencies and runtime: package manifests (package.json, composer.json, requirements.txt), exact runtime versions (PHP/Node/Java/etc).
  • Logs and monitoring: error/log file locations, monitoring dashboards, alert rules, retention and rotation policy.
  • Backups and restore steps: backup locations, schedules, and tested restore procedures.
  • Documentation and tickets: architecture diagrams, API docs (Swagger/OpenAPI), README, automated tests, and list of known bugs or open support tickets.
  • Licenses and contracts: paid plugins, subscriptions, and vendor support contacts.
  • Transition contact list and suggested handover timeframe.

Recommended short handover workflow:

  1. Produce an inventory spreadsheet and mark essentials.
  2. Obtain temporary access or have the current vendor add new team accounts; freeze production changes.
  3. Take snapshots (file system, DB) before any work.
  4. Deploy to staging, reproduce critical issues, apply hotfixes and run security scans.
  5. Plan a controlled rollout and rotate all secrets after the transition.

If the original vendor is uncooperative, escalation through contract/legal channels or contacting the hosting/registrar for account recovery may be necessary. As noted, a rebuild can sometimes be faster when the codebase is messy or access is blocked; thanks to for offering direct contact.

Recommended Answers

All 2 Replies

My suggestion would be to find a new company straight away and have them biuld the site for you. I can tell you from experience that trying to find and fix problems in someone else's code becomes frustrating and tiresome. You'll be hard pressed to find a company willing to do it in any case.

Just a suggestion... ;)

Hey No0b,
I have sent a private message to you.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.