Secure access before you announce anything — and know that three of the four things you need can be obtained without the developer’s cooperation at all. Follow the order below and downtime is usually zero.
One useful thing about this corner of the market: almost nobody advertises for it. Top-of-page bids on website transfer searches sit under ₹8 in NCR, which means very few companies compete to help people in your position. You’ll need to look for migration help deliberately — and you’ll get better attention than in the crowded new-build market.
Step 1: Find out what you actually hold
Ten minutes, and it changes the whole plan.
- Run a WHOIS lookup — search “whois” plus your domain. Read the registrant email and the expiry date.
- Search your own inbox for a registrar welcome email — GoDaddy, BigRock, Namecheap, Hostinger. If one exists, the account may already be yours and need only a password reset. This resolves more cases than people expect.
- Try logging in to hosting. Not “you forgot the password” — check whether you were ever given one.
- Try your site admin — usually your address followed by
/wp-adminon WordPress.
Remember: control follows the registrar account, not who paid. Who really owns a domain.
Step 2: What you can get without them
| What you need | How to get it without cooperation |
|---|---|
| Domain, in your name | Log in and reset the password via your own email |
| Domain, in their name | Registrar ownership-claim process — they’ll weigh GST registration, invoices, payment records, trademark |
| Hosting | Contact the hosting company directly as the account owner |
| A backup | Generate and download it from hosting once you have access |
| Site admin | Resettable through hosting |
| Design source files | Genuinely needs their cooperation — and a new developer rarely needs them |
Notice that hosting access delivers the backup and the admin login. So there are really only two objectives: the domain, and hosting.
Step 3: The message that decides the outcome
Framing matters more than entitlement, and timing matters more than framing. The same request gets answered on a quiet Tuesday and ignored during a payment argument, because the access is the leverage.
Send this before announcing any departure:
Hi [name]. For my records, could you please send the domain registrar login or transfer code, the hosting login, the website admin login, and a full backup of the site as a zip? Also, please confirm whether anything — Google Business Profile, analytics, business email, payment gateway — is registered under your account for my business. Happy to settle any pending amount on receipt.
Four deliberate choices: no grievance, specific items so “I sent you everything” isn’t available, a question about registrations you may not know exist, and a reason for them to reply.
If there’s a genuine unpaid balance, pay it. A few thousand rupees to end a hostage situation is the cheapest option available.
Step 4: The six friction points
| Friction | Cost to clear | Time |
|---|---|---|
| Domain not in your name | Free to modest | Days to weeks |
| No hosting access | Free | Days |
| No admin access | Free, via hosting | Hours |
| 60-day transfer lock | Nothing — just time | Up to 60 days |
| DNS propagation | Free | Hours to 2 days |
| Page addresses changing | A developer’s hour | Do it during the move |
Two of these surprise people:
The 60-day lock. Domains recently registered or transferred are typically locked against transfer for around sixty days. Standard registrar practice, not obstruction, and nobody can override it. You can still change hosting during the lock, since that’s separate from moving registrar.
Page addresses. If a rebuild changes every URL without redirects, you lose whatever search visibility you’d accumulated. This is the most commonly skipped step in a migration and the costliest to fix later.
Step 5: The order that avoids downtime
- Secure access first — before announcing anything.
- Download a full backup — files and database — and keep your own copy off the server.
- Note every current page address, or ask the new developer to crawl the site and list them.
- Set up new hosting and get the site working there on a temporary address, before switching anything.
- Then point the domain at the new hosting.
- Keep the old hosting live for a week. Cheap insurance against propagation gaps.
- Check redirects and forms afterwards, from your own phone.
Follow that order and downtime is usually zero. Skipping step 4 is what causes a site to be dark for two days.
Step 6: What to ask the new developer
Three questions, answers in writing:
- “Will the domain stay in my own account?” The answer must be yes.
- “How will you handle redirects from my existing page addresses?” A specific answer.
- “Will you keep the old site accessible until the new one is verified?” This is what makes a rollback possible.
Then also settle the post-launch change rate and response time, since one common reason for moving is that nobody answered after payment.
Step 7: Leaving the old developer properly
Settle any genuine balance. Cheap against a contested handover.
Send one civil message, no explanation of why:
Hi [name]. I’m moving the website management elsewhere. Could you confirm the hosting login and site admin login, and let me know whether anything is registered under your account for my business? Happy to settle anything pending. Thanks for your work.
Don’t burn it. A developer you part from politely will usually answer one question six months later. One you’ve argued with won’t. When and how to leave.
Step 8: Set it up so this can’t recur
- Domain in your own registrar account, your email, auto-renew on, current card, expiry in your calendar with a 30-day reminder.
- Hosting in your own name, on your own card, with its own expiry date noted.
- Give developers access, not ownership — registrars and hosts both support adding a user or sharing DNS.
- Get the nine-item handover in writing at launch, and test each item rather than filing it. The checklist.
What to do this week
- Run a WHOIS lookup and read the registrant email and expiry date.
- Search your inbox for a registrar welcome email and try a password reset.
- Contact your hosting company directly as the account owner.
- Send the records-keeping message today, before announcing anything.
- Download a backup and keep your own copy off the server.
If you want it done the certain way
Tell us your domain and what access you currently hold. We’ll map the migration — what’s recoverable without the old developer, whether the 60-day lock affects your timing, and how redirects will be handled — before you commit to anything. Domain and logins end up in your name. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- Website rescue: recover your domain, hosting and site
- The friction of moving to a new developer
- Whose name is your domain registered in?
- Hosting hostage: warning signs a developer controls your site
- What finally makes you leave your old developer
FAQ
How do I transfer my website to a new developer or host?
Secure the domain and hosting access first, download a full backup, get the site working on new hosting at a temporary address, then point the domain across and keep the old hosting live for a week. Announce the move only after you hold access.
Can I move my domain if the developer won’t cooperate?
Often yes. If it’s registered in your name, reset the password via your own email. If it’s in theirs, registrars have ownership-claim processes that weigh GST registration, invoices and payment records.
Why can’t I transfer my domain immediately?
Domains recently registered or transferred are typically locked for around sixty days. That’s standard practice and nobody can override it — but you can still change hosting during the lock, since that’s separate.
Will moving my website affect my Google ranking?
It can if page addresses change without redirects. Get written confirmation from the new developer on how old URLs will redirect to new ones before work starts.
How do I avoid downtime during a website migration?
Get the site fully working on the new hosting at a temporary address before pointing the domain, then keep the old hosting running for a week to cover DNS propagation.
