Usually, yes. Moving the parent domain to another registrar does not normally wipe out child nameservers such as ns1.example.com or ns2.example.com. The bit worth checking is whether the new registrar lets you manage those existing host records properly.
Short answer
If example.com has registered child nameservers at ns1.example.com and ns2.example.com, transferring example.com to a new registrar should not remove those registry host objects. What can change is how easy they are to see or edit in the gaining registrar's control panel.
This is one of those domain-transfer questions where the control panel can make the situation look worse than it is. A registrar might call them child nameservers, host records, personal nameservers or glue records, and the menu can move completely when you transfer.
The important thing is not whether the new dashboard looks the same. It is whether the registry still has the host objects and IP addresses that make those nameservers work.
If you own example.com and create ns1.example.com, that hostname sits underneath the same domain. For it to work as a nameserver, the registry needs to know the server IP associated with it. That registry-level host information is what people usually mean when they talk about glue or a child host record.
That is different from simply setting example.com to use nameservers owned by somebody else, such as ns1.provider.net. In that case, the nameserver belongs to provider.net and there is no child host under example.com to move.
If you are using ordinary third-party nameservers, there is usually nothing special to migrate. If you are running ns1.example.com yourself, the host object and its IP address are part of the setup you should verify after a registrar transfer.
Under the standard EPP model, subordinate host objects follow the domain rather than being transferred separately.
RFC 5731 says that when a domain transfers, subordinate host objects transfer with it. RFC 5732 makes the same point from the host side: a host object underneath a domain is not transferred independently of that domain.
So if example.com moves registrar, properly registered hosts such as ns1.example.com should remain at registry level. You should not have to delete them before the move and recreate them afterwards.
Nominet documents the same general behaviour for in-bailiwick host objects in the .UK namespace, where the host follows the parent domain.
This is the part I would check before touching anything. With a large domain portfolio, I have learned not to assume that a missing menu entry means the registry data has vanished. Registrar dashboards vary a lot, especially around child nameservers.
One registrar may show an obvious “registered hosts” screen. Another may bury the same setting under advanced DNS. A third may require support to expose an existing host object after a transfer.
If the first two checks are fine, I would not start deleting and recreating nameservers simply because the new control panel looks unfamiliar.
For the registry-IP side of this setup, see our separate guide to what happens to glue records when a domain transfers.
Child nameservers can still stop working around the same time as a registrar move, but that does not mean the transfer itself deleted them. The failure is more often one of these:
ns1.example.com still exists, but the server has moved to a different IP and the registry host record was never updated.
The hostname can remain perfectly valid while the machine behind it no longer answers DNS queries.
The registry object is still there, but the gaining registrar's interface does not give you a working way to update it.
There is also a wider dependency to think about. If other domains use ns1.example.com, changing or breaking that one child nameserver can affect every domain delegated to it. I would treat it as infrastructure rather than a minor registrar setting.
If the child nameservers matter to live websites or email, I would save the current hostnames and IP addresses before starting the transfer. It takes a minute and gives you something concrete to compare afterwards.
I would also check that the gaining registrar actually supports management of registered hosts or personal nameservers. Cheap transfer pricing is not much use if you later discover that a basic DNS function you rely on is awkward or unsupported.
You can move the registrar and keep the same nameservers. The two operations are separate. If you deliberately change both at once, troubleshooting becomes harder because you have changed two pieces of the DNS setup at the same time.
If you are still choosing where to move the domain, our domain transfer comparison is useful for comparing the transfer cost separately from the DNS decision. We also have a guide on keeping your existing nameservers when changing registrar.
The part that matters
If the host objects and glue are correct before the move, they should normally continue working afterwards. Check what the registry is actually publishing before you rebuild anything just because the gaining registrar presents the settings differently.
