Transferring a domain frightens people more than it should, and the way it gets described is to blame. Many providers present it as a delicate operation that could cause disruption — convenient for anyone who does not want to lose a customer, but not true.
Here is what actually happens, for an .it.
First: a transfer does not touch the website
This is the point that removes ninety per cent of the anxiety. Transferring a domain changes who invoices you for it, not where it points.
A domain separately has:
- a registrar, the supplier through which it is registered;
- nameservers, whoever answers questions about it.
A transfer changes the first. The second stay exactly as they were, and with them the website, the mail, the subdomains and everything else. If you do not touch the DNS zone, nobody notices — customers included.
Disruption only appears if you change the hosting along with the registrar. Those are two distinct operations, and it is worth keeping them distinct, in time as well.
The authinfo code
Moving an .it requires an authorisation code, called authinfo. It is the proof that whoever is requesting the transfer has the right to request it.
Two important things about that code.
It goes to the Registrant, not to whoever asked for it. The Registry's rules are explicit: authinfo is communicated to the email address of the holder as recorded in the domain's data. Not the technical contact, not the agency.
Which makes the email in the domain record more important than the name. If the Registrant is your company but the email belongs to whoever built your site, the code goes to them. That is why, before any transfer, ownership gets verified — and if the email is not yours, that gets corrected first.
If the current provider will not supply the code, you are not stuck: the Registry has a procedure for obtaining it, designed for exactly these cases.
The timing: 24 hours, not days
Here .it is faster than the international extensions, and the difference is stark.
Once the request is submitted with the correct authinfo, the domain enters a pending-transfer state lasting at most twenty-four hours. Within that window the old registrar may explicitly refuse. If it does not, once the time passes the Registry approves it itself and the transfer completes.
The old provider does not have to say yes. It only has to not say no, and a refusal has to be justified.
For comparison: on .com and the other international extensions, ICANN's rules allow up to five days, and the domain is locked for sixty days after a recent registration or transfer. .it has no such sixty-day lock.
When a transfer is refused
The legitimate cases are few, and they are worth knowing, because knowing them tells you when a refusal is instead just obstruction:
- the domain was registered or transferred very recently — there is a minimum period before it can move again;
- there is an open dispute over the name;
- the authinfo is wrong or expired;
- the Registrant's details do not match those on the request.
Unpaid invoices are not on that list. A supplier can be entirely right about the money and still have no standing to hold the domain: they are two separate matters, and it is worth saying so calmly before it becomes a fight.
The sequence I use
- Check the domain record. Who the Registrant is, which email is recorded, which registrar holds it, when it expires.
- Correct the email, if needed. This is the step almost everybody skips, and it decides all the rest.
- Unlock the domain at the current registrar, if a transfer lock is on.
- Request the authinfo, which arrives at the Registrant's mailbox.
- Start the transfer at the new registrar, with the code.
- Wait, a day at most.
- Final check: the new registrar appears in whois, the nameservers are still the old ones, and the site and mail answer exactly as before.
- Auto-renewal and transfer lock switched back on at the new account, along with two-factor authentication.
Step 7 is short but is not skipped: it is where you occasionally discover that the old provider was hosting the DNS zone on their own nameservers, and that you now need to decide where it should live.
The case that complicates everything
There is one situation the sequence above does not cover on its own: when the DNS is hosted by the provider you are leaving. It is not rare, and it is logical — they gave it to you along with everything else.
In that case the registrar transfer is still painless, but sooner or later those nameservers will disappear, and the site and mail with them. The answer is to move the DNS zone before the transfer rather than after: rebuild it elsewhere, verify it record by record, change the nameservers, wait until everything answers from the new place, and only then move the registrar.
Done in that order, there is no moment when anything depends on a supplier you are about to leave.