DIRECT ANSWER
If you control the domain, the hosting account and a complete copy of the site files, a new developer can take over with little disruption. If any of the three sits only in the developer's name, you may be unable to change, move or even reach your site. Ask for these in writing before the work starts, and confirm them again after launch.
Key terms
- Domain registration
- The record of who holds the rights to a website address. The registrant controls where the address points.
- Hosting account
- The service that stores a site's files and serves them to visitors. Whoever owns the account controls access to the live site.
- Code handoff
- Delivery of the complete files and instructions needed for another provider to host and maintain a site.
- Portability
- How easily a site and its content can move from one provider or platform to another without being rebuilt.
Where sites get stuck
Developers retire, agencies close and freelancers stop answering. A website usually survives that. What fails is access. The business discovers that the domain is registered under the developer's account, that the hosting is billed to a card it cannot see, or that the only copy of the site files sits on someone else's computer.
The risk does not depend on the technology. A WordPress site, a builder site and a custom-coded site can each be locked behind accounts you do not control. The technology decides what moving looks like once you have access. Access decides whether you can start.
The five things to control
| What to control | Why it matters | How to check |
|---|---|---|
| Domain registration | Whoever holds it decides where your address points | Look up the registrant, or log into the registrar yourself. Your business should be the registrant, with an email you read |
| Hosting account | It controls the live site and any forms or functions tied to it | Confirm you can log in, or that you are named as the owner or a collaborator |
| Site files and source | A complete copy lets a new provider rebuild or redeploy | Ask for the files or repository export and open them. A copy you have never opened is not a backup |
| Accounts for connected services | Forms, email, analytics, booking and payments each have their own login | List each tool and confirm you hold the admin login |
| A written handoff | It states what is delivered and what is not | Keep the signed scope and the handoff list together with the files |
How moving a site works
How hard it is to move depends on how the site was built.
A site delivered as ordinary files can be deployed to many hosts. Netlify, for example, documents deploying from a Git repository, from the command line, by dropping a folder or through its API, and notes that a project's source in a repository is already portable [1]. A static site generator outputs HTML, CSS and JavaScript files that a browser can display directly [2]. Another host can serve those files.
A site that depends on a server-side application and database needs more to move: the code, the database content, the server environment and any plugins [3]. A site built inside a proprietary editor may export only part of what you see. Before relying on any platform, find out what an export produces and test it.
Portability has limits for every approach. Moving between platforms can require conversion, redevelopment, form and analytics replacement, DNS changes and testing, and that work can be billable. A custom site cannot be assumed to transfer unchanged into a different proprietary platform.
What to ask before the project starts
- Who will be the registrant of the domain? The answer should be your business.
- Who owns the hosting account, and who pays? Either you own it, or the agreement states the hosting arrangement and what happens when it ends.
- What is delivered at the end? Ask for the files, content, configuration notes and a list of third-party dependencies.
- What does a release or transfer cost? A clear answer, ideally none for paid work, prevents a dispute later.
- Which parts belong to the builder? Reusable tools, templates and licensed components often stay with the builder or the license holder. Know which parts so a new developer can plan around them.
Compare the answers across proposals using how to compare website proposals and costs.
Applications
A dental practice after an agency closes
Illustrative example. A dental practice learns its agency has closed. The practice holds the domain, so it can point the address wherever it chooses. It also has a files export from launch day. A new developer deploys the files, reconnects the form and has the site running within days. The practice's early insistence on being the registrant and receiving files is the reason.
A contractor locked out of a builder account
Illustrative example. A contractor's site sits in a builder account opened by a freelancer who has stopped answering. The domain is registered through the same account. The contractor can recover the address only by proving ownership to the provider, which takes weeks, and the content must be recreated because the builder offers no full export. Nothing about the site's quality caused the problem. The accounts did.
Limits and edge cases
- Third-party licenses transfer separately. Fonts, stock images, plugins and software keep their own terms, and a new provider may need new licenses.
- Integrations need new connections. Forms, bookings and payments are tied to accounts, as covered in links, embeds and integrations. Rebuilding them is part of any move.
- Credentials should move securely. Passwords belong in a password manager or a secure transfer, not in an ordinary email or form.
- A handoff is not an ongoing service. After the handoff, hosting, updates, backups and uptime belong to whoever you choose next, unless a plan says otherwise.
How So It Sticks applies this
Our terms state that clients are not required to stay on our hosting indefinitely. Every launched site stays live on our hosting for at least 30 days, and by the end of that window the client either chooses a service plan or receives the complete code handoff. We do not charge a special release fee for the paid, client-specific deliverables. We also say plainly that a custom site cannot be assumed to move unchanged into Wix, Squarespace, Shopify, WordPress or another proprietary platform, and that migration work can be priced separately. We recommend that the client hold the domain registration. Start a Project Brief and we will walk through the handoff before any work starts.
Sources and method
The checklist and examples are So It Sticks editorial frameworks. The examples are illustrative and describe no real business. Each linked source supports only the statements numbered beside it. Sources verified October 16, 2026.