Changing the people who look after a running system is not the same job as changing the people who look after a website. A brochure site can go quiet for a weekend and nobody loses money. A booking engine, a customer portal or an ordering system cannot.
That difference changes the whole sequence. With a marketing site you are mostly protecting files, content and rankings. With a live system you are protecting transactions in flight, scheduled jobs that run at 2am, payment settlements, and a database that is being written to while you argue about the handover. If your project is a marketing site rather than a system, changing web designer without losing your site is the right guide instead.
This one covers the four things that decide whether switching web developers goes cleanly: the pre-switch audit, the access inventory, the overlap period, and what the new team should be doing in the first 90 days. It is written for Malaysian SMEs running something that customers or staff use every day.
The video below explains what a proper handover is meant to contain and when it should happen.
1. What Makes Switching Developers Harder Than Changing Designer?
Quick Answer: A website can be copied. A running system has to be transferred while it keeps running. Switching web developers means moving live data, background jobs, payment connections and undocumented business rules at the same time, which is why our web development team treats it as a project with its own plan rather than an admin task.
The word "handover" makes it sound like passing a folder across a desk. On a live system it is closer to changing the driver of a moving vehicle.
Four things exist in a system that do not exist in a marketing site, and each one is a place a switch goes wrong:
- State. There is a database with real orders, balances and bookings in it. It cannot be recreated from a backup file that is two weeks old.
- Scheduled work. Cron jobs, nightly syncs, reminder messages and settlement reports run without anyone watching. They break silently.
- Money connections. Payment gateways, accounting syncs and invoicing all sit behind keys registered to somebody.
- Rules that live in code, not documents. Approval limits, discount logic, stock deduction order. Nobody wrote them down, and the person who knows them is leaving.
That last one is the expensive one. On a marketing site the knowledge is visible on the screen. On a system it is buried, which is why the web app requirements document written at the start is worth more during a switch than at any other moment. If nobody wrote one, the switch is where you pay for it.
Key takeaway: Treat the switch as a transfer of a live operation, not a delivery of files. The files are the easy part.
Not sure whether the problem is the developer or the project?
Some systems do not need a new team, only a reset on scope and sequence.
See how a stalled web project gets rescued →2. What Should the Pre-Switch Audit Cover?
Quick Answer: Seven checks, run quietly before anyone gives notice: access, repository, server jobs, third-party keys, a tested restore, environment parity, and undocumented rules. Around twelve working days in total. Running it after notice is given costs you leverage, because the outgoing team is no longer motivated to answer.
The audit exists to answer one question: if this developer stopped replying tomorrow, what could we not do for ourselves? Do it while the relationship is still normal.
Here is the check list we work through on Malaysian SME systems, with how often each check turns up something the client did not know about.
| Check | Who runs it | Working days | Found a problem |
|---|---|---|---|
| Access and credential inventory | You, with a written list | 2 | 78% |
| Undocumented business rules | Your operations staff | 3 | 71% |
| Backup and restore test | Incoming developer | 1 | 66% |
| Server, cron and background jobs | Incoming developer | 2 | 61% |
| Repository history and branch state | Incoming developer | 1 | 54% |
| Third-party keys and renewal dates | You, with accounts | 1 | 47% |
| Environment parity, staging against live | Incoming developer | 2 | 43% |
Highlighted row is the check that most often finds something. Working days assume a single-system SME build and run in parallel where possible. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom system handovers. Licence.
Two of those checks are yours, not a developer's. You are the only one who can list which staff know which rule, and you are the only one who can pull the invoices that show which third-party services you actually pay for. A restore test also belongs on the list whether or not you are switching — a backup nobody has restored is a hope rather than a plan.
Key takeaway: Run the audit before notice, not after. Once notice is given, every question you ask costs goodwill you no longer have.
3. Which Access Must Be in Your Name Before You Give Notice?
Quick Answer: Six accounts must be owned by your company, not your developer: the domain registrar, DNS control, the production server, the code repository, the payment gateway merchant account, and business email. Deployment keys are the seventh and the most commonly missed. Ownership of your domain and files is the base layer under all of it.
Ownership means the account is registered to a company email address you control, with billing on a company card. A developer being "an admin on our account" is fine. Your company being a user on their account is not.
This is where most SME switches start from a weak position.
| Credential | Held by the client at the start | Share | If not, the fix |
|---|---|---|---|
| Domain registrar account | 68% | Registrar transfer, 5–7 days | |
| Business email administration | 61% | Super-admin reassignment | |
| Payment gateway merchant account | 57% | New merchant application | |
| DNS zone control | 44% | Re-point nameservers | |
| Production server root access | 31% | Migrate to your own account | |
| Code repository ownership | 24% | Transfer to a company org | |
| Deployment and CI keys | 12% | Rotate every key at cut-over |
Highlighted row is the least-held credential and the one most often forgotten at cut-over. Bars are proportional to the share column. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom system handovers. Licence.
Deployment keys sit at the bottom for a boring reason: nobody sees them. They are not a login screen, so they never appear on a checklist. But a deploy key left active after a switch is a door into production held by a company you no longer work with.
The same trap exists in Google's tools. Removing someone from Search Console does not remove their verification token, and Google's own documentation on managing owners, users and permissions notes that a removed owner can simply re-verify unless the token itself is deleted. Revoking access and revoking the ability to regain access are two separate jobs.
Access hygiene is also a legal matter once customer records are involved. The security principle in Malaysia's seven personal data protection principles under Act 709 puts the duty to prevent unauthorised access on you as the data user, not on the supplier who happens to still hold a password. Broader controls are covered in PDPA security for web systems.
Key takeaway: Write down every credential, then write down who could still get back in after it is revoked. The second list is the one that protects you.
Want a second pair of eyes on the incoming team?
The vetting questions for a system build are not the ones people usually ask.
Run the 12 technical checks before you sign →4. How Long Should the Overlap Between Developers Be?
Quick Answer: Fourteen to thirty days, paid, with the old team on questions only and the new team doing the work. Shorter than fourteen days and the new team meets the system's quirks alone. Longer than thirty and you pay two suppliers for comfort rather than safety, because nobody is forced to finish the transfer.
The overlap is the part of switching web developers that people try to get for free, and it is a paid contract, not a favour. Write it as a fixed retainer with a defined response time and a stated end date, the same way you would treat any other exit term in a supplier contract. Goodwill has no service level.
What overlap length actually buys, measured on switches we have run:
| Overlap arranged | Incidents in 90 days | Unplanned downtime | Callbacks after handover | Cost against quote |
|---|---|---|---|---|
| None, clean break | 9 | 14.5 hours | 6 | +22% |
| 7 days | 6 | 7.0 hours | 4 | +14% |
| 14 to 30 days | 2 | 1.5 hours | 1 | +4% |
| 60 days or more | 2 | 1.0 hours | 1 | +11% |
Highlighted row is the best value band. Cost against quote compares total switch spend, including the overlap retainer, with the transition fee quoted at the start. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom system handovers. Licence.
The interesting row is the last one. Sixty days buys almost nothing over thirty on incidents or downtime, yet costs more than double the overrun. Long overlaps remove the deadline, and without a deadline the knowledge transfer never quite finishes.
Three rules make an overlap work:
- The new team does the work from day one. If the old team keeps deploying, nothing is being transferred.
- Questions go in writing. A shared thread or ticket queue, not phone calls, so the answers survive the overlap.
- The end date is in the contract. Along with the hours included and the response time expected.
Key takeaway: Pay for 14 to 30 days of answers, not 60 days of availability. The deadline is what makes the handover actually happen.
5. What Documentation Must the Outgoing Developer Deliver?
Quick Answer: A runbook a stranger can follow: how to set the project up locally, how to deploy, where every scheduled job lives, which third-party services are connected, how to restore a backup, and the business rules that are not obvious from the screens. Test it by using it, not by reading it.
Documentation is the deliverable people accept without checking, because it looks complete. A twenty-page document that nobody has followed end to end is decoration.
The list to demand, written into the exit clause rather than requested politely:
- Setup instructions. From an empty laptop to a running local copy, including versions.
- Deployment steps. How code gets to staging and to production, and how a bad release is rolled back.
- Scheduled jobs. Every cron, queue worker and nightly sync, with what it does and what breaks if it stops.
- Connected services. Gateway, accounting, messaging, storage, with account names and renewal dates. Gateway specifics sit in payment gateway integration from FPX to Stripe.
- Backup and restore. Where backups go, how often, and the exact restore procedure.
- Business rules. Approval limits, pricing logic, stock deduction order — the things that are true only in code.
How to prove the handover is actually complete
Five steps, run during the overlap while the old team can still answer.
- Rebuild on a clean machine. The new developer sets the project up on a fresh laptop using only the written instructions, with no help.
- Deploy to staging from the runbook. Following the document exactly, with every gap logged as a correction the old team must make.
- Restore last night's backup into staging. A backup that will not restore is not a backup, and this is the cheapest moment to find out.
- Run one real transaction end to end. An order, a booking or an invoice, through payment, notification and the accounting sync.
- Rotate every credential, then repeat step two. If the deploy still works after every key is changed, the transfer is real.
Step five is the one that gets skipped, and it is the only step that proves the old team is no longer load-bearing. Where staging and live have drifted apart, bringing the two environments back into sync comes before anything else, and the wider sequence of discovery, staging and UAT is set out in the web development process.
Key takeaway: Accept documentation only after somebody has used it to rebuild and deploy the system without asking a question.
Unsure what ongoing support should cost after the switch?
Support, hosting and SLA cover are priced very differently for a system than for a website.
Compare web app maintenance and SLA plans →6. What Should the First 90 Days Look Like?
Quick Answer: Stabilise first, then improve. Expect the new team to fix and learn for the first month, ship small changes in the second, and only take on new features in the third. If they promise new features in week two, they have not read the code yet.
A switch is not finished on the day the old contract ends. It is finished when the new team can handle a problem at 9am on a Monday without calling anyone. Here is the shape that takes.
| Window | New team's focus | Incidents logged | Needed the old team | Releases shipped |
|---|---|---|---|---|
| Days 1–15 | Access, rebuild, restore test | 7 | 54% | 1 |
| Days 16–30 | Monitoring, backups, small fixes | 5 | 38% | 3 |
| Days 31–45 | Documenting rules found in code | 3 | 19% | 5 |
| Days 46–60 | Performance and security cleanup | 2 | 8% | 6 |
| Days 61–75 | First agreed improvements | 1 | 3% | 8 |
| Days 76–90 | Normal roadmap work | 1 | 0% | 9 |
Highlighted row is the point at which the switch is complete. Incidents cover anything raised as a fault by staff or customers. Source: ZenWeb client sample, 500+ Malaysian SME accounts, 2024–2026, custom system handovers. Licence.
Two numbers matter here. Incidents fall by roughly six in seven between the first fortnight and the last, and the share needing the old team reaches zero by day 90. If either curve is flat at day 60, the handover did not transfer knowledge — it transferred a login.
A handover is finished when the new team stops asking questions, not when the old contract ends.
Keep watching the boring signals through this window too — uptime, backup success, and whether the system stays reachable after each release. If a server move is part of the switch, sequence it separately using the no-downtime host migration steps rather than bundling it into week one, and if the system's public pages carry traffic, watch for the traffic drop that follows a rushed migration. Routine hardening such as patching and login security belongs in the days 46 to 60 window, not the first week.
Key takeaway: Judge the new team on how fast they stop needing the old one, not on how fast they ship the first feature.
7. Switch on Your Terms, Not on Theirs
Quick Answer: Audit, then secure access, then give notice, then overlap for 14 to 30 days, then measure the first 90 days. Done in that order, switching web developers is a project. Done in the reverse order it is an emergency, and emergencies are where systems and data get lost. Our web development team takes over systems in that sequence.
Most bad switches share one cause: notice was given before the client knew what they held. Everything after that is negotiation from a weak seat.
The order is the whole trick. Know what you own, take what is yours, then have the conversation. Before signing with anyone new, settle the ownership terms — who owns the source code, and what the exit clause in the contract actually promises, in the same spirit as the clauses covered in a web design contract. Whether the next team should be a firm or an individual is covered in freelance developer against software house, and whether to bring the work in-house at all in in-house developers against outsourcing. Outside the Klang Valley, the local hiring picture is set out in the Penang hiring guide for SMEs.
Once the new team is in place, the habits that keep you safe are the ordinary ones: know what a developer in Malaysia should cost, keep a working rhythm with your developers, budget for maintenance that is not optional, and understand the basics you are paying for, such as what web hosting actually is and how domain names work. If your team also updates content directly, safe self-service editing is worth setting up early.
When you are ready to move a live system, talk to ZenWeb web development — we run the audit before you give notice, not after. You can see how we work across the rest of the business at ZenWeb.
Thinking of moving your system to a new developer?
Book a free 30-minute session before you give notice. We will walk the access list with you, flag what is not in your name yet, and map an overlap plan that fits your system. You keep the notes, whether you move to us or not.
Get my free switch review →
8. Frequently Asked Questions
1. How do I switch web developers without downtime?
Start switching web developers with the audit, before giving notice, move every credential into your company's name, then keep the outgoing team on a paid 14 to 30 day overlap while the new team rebuilds the project from the runbook, restores a backup into staging and rotates the keys. Downtime in a switch almost always comes from a missing credential or an unknown scheduled job, both of which the audit finds first.
2. What should the outgoing developer hand over?
Setup instructions from an empty laptop, deployment and rollback steps, a list of every scheduled job, all connected third-party services with account names and renewal dates, the backup and restore procedure, and the business rules that exist only in code. Accept it only after the new developer has used the document to rebuild and deploy the system without asking a question.
3. How long should the overlap with the old developer be?
Fourteen to thirty days, paid, with the old team answering questions and the new team doing the work. On our client sample that band produced a median of two incidents in the first 90 days against nine with no overlap. Sixty days or more added cost without reducing incidents, because a long overlap removes the deadline that forces the transfer to finish.
4. What access do I need before I give notice?
The domain registrar, DNS control, the production server, the code repository, the payment gateway merchant account and business email should all be in your company's name. Deployment and continuous integration keys are the most commonly missed, held by only 12% of clients at the start of a switch. Revoke access and remove any verification tokens that would let a removed user re-verify.
5. Is switching developers different from changing web designer?
Yes. A marketing site can be copied and rebuilt; a running system has live data, scheduled jobs, payment connections and business rules buried in code, and it has to keep working while it is transferred. The steps that protect a website — files, content, rankings — are necessary but nowhere near enough for a booking engine, portal or ordering system.
