Every year, in the animal kingdom, there are some awe-inspiring migrations. One, known appropriately as the "Great migration", involves the mass exodus of vast groups of wildebeest, some comprising over one million individuals. These mega-herds roam for hundreds of miles across the Serengeti in search of fresh grass and available water and their migration takes them across two counties, Tanzania and Kenya.
The driver behind this relocation of the wildebeest is to find pastures new, in which they can grow and thrive. This is because it has become increasingly difficult to exist in the environment in which they currently inhabit.
Along the way, the face many dangers, both seen — such as lions and hyenas — and unseen, from the wily crocodiles that gather in places the wildebeest trails ford fast flowing rivers and pick off the stragglers from below the surface.
The great domain migration
Up until the launch of new gTLDs in 2013, migrations of top-level domains between Technical Registry Operators (RSPs), were typically few and far between. Indeed, in the preceding fifteen years, you could probably list registry migrations on the fingers of one hand.
However, since 2017, when registry contracts started coming up for renewal, there has been a surge in registry back-end migrations as Registry Operators re-evaluate their needs. Since 2017, CentralNic has migrated in over 40 TLDs from other providers.
Beware of crocodiles
There are four key things that registry operators should be aware of when considering crossing the crocodile infested river to another registry back-end operator:
Exiting contracts
As with all business relationships, major problems tend to occur when one party is trying to end that relationship. Both parties enter into an agreement full of hope and enthusiasm and the Registry Operator in particular usually accepts terms and conditions around exiting contracts which are quite punitive because they are focused on launching a business and cannot foresee having to end that relationship.
🐊Just like a crocodile, hiding under the water and waiting to strike, the acceptance of stringent notice periods, exit clauses and payments initially can come back to bite a Registry Operator when it comes around to changing registry partner for commercial reasons.
Practical advice: When selecting a new Registry Service Provider, make sure to evaluate its legal team, which should have experience in helping Registry Operators to exit registry contracts while minimising potential exit penalties.
Migration process
Registry Data must be prepared by the existing RSP and delivered to the new RSP in accordance to a strict, mutually agreed migration plan and schedule. For a migration to work seamlessly, both RSPs must work closely together.
The primary role of the incumbent RSP is to ensure that the correctness of the registry data and the integrity of the datafile submitted to the new RSP. The role of the new RSP is to create the migration tools necessary to take the Registry Data supplied by the incumbent RSP and convert it into a form that can be imported into the new registry platform.
🐊The crocodile waiting in ambush here is the lack of motivation of the incumbent provider to assist in this process. While the Registry Operator and the new RSP are keen to migrate the registry to the new platform, the incumbent provider has no incentive or motivation to put technical resources or any urgency to this task.
Practical Advice: When selecting a new RSP, check how many in-bound migrations they have performed previously, especially from the incumbent provider. Find out in advance what issues were encountered in the past and how the RSP dealt with them. Don't forget to ask to see a migration plan that has been used in action.
Registrar onboarding
Registry data migration is a very small part of a registry migration project. The actual migration of data normally takes no more than a day and often just a few hours. However, it is crucial that all existing registrars that manage domain names on behalf of their clients are able to successfully connect to the registry system and can register, renew, delete and modify their customers' domain name data.
🐊The crocodile lurking here is that a Registry Migration also requires action by the Registrar to modify their own customer portals and registration systems to work on the new registry system. If it is difficult for existing registrars to connect to the new registry system this might put migration timelines at risk.
In order to give the registrar sufficient time to schedule the integration and testing work a structured registrar communications project is recommended. Such as programme can take place over several months and involve multiple communications channels.
Practical Advice: When selecting a new RSP, check that it already has connections to the TLD's existing accredited registrars with domains under management as well as the total number of registrars connected to the platform.
Ask to see a Registrar communications plan and how many in-bound migrations the Technical Registry Operator has performed previously, especially from the incumbent provider. Find out in advance what issues were encountered in the past and how the RSP dealt with them. Don't forget to ask to see a migration plan that has been used in action and, if possible talk to a Registry Operator that has gone through a migration onto the platform.
Policy implementation
When moving to a new back-end registry platform, it is essential that as far as possible all registry policies and domain lifecycle can be modelled either as is or with the minimum of practical changes. Good up-front advice will make any migration much smoother. RSPs should have staff experienced in Registry policy creation and management.
An up-to-date industry recognised registration policy and domain lifecycle will often make the registry migration process easier for all parties including registrars. Simplifying and modernising policies and processes will often reduce costs at the registry and registrar and make the TLD a more attractive proposition for registrar marketing.
🐊The crocodile waiting to bite here concerns whether or not the registry needs to obtain approval from ICANN for changes that it wishes to make to Registry policies Such changes may involve a complicated submission to ICANN and encounter lengthy delays in obtaining approval. Registrars will also require notice of policy changes to ensure that they reflect policies in their agreements with Registrants.
Practical Advice: Before migrating a registry onto a new registry technical platform it is recommended to review existing policies (such as Registration, billing, marketing, promotions) for fitness for purpose. Often, existing policies can be made more efficient and workable with a few straightforward changes and simplifications. Policies which have been in place for a long period of time should be updated to reflect the current state of the domain name industry and customer expectations.
Conclusions
While, at first glance, the migration of a registry back-end between RSPs may appear to be a purely technical operation, this is far from the case. The change of registry system provider should not be treated as an isolated project but should be used as a reason to evaluate other registry operation factors such as Registration Policies and procedures, domain lifecycle, billing mechanisms, domain pricing, registry products, domain abuse mechanisms, and registry promotions.
Check to ensure that your RSP of choice has expertise in all of the following areas: Policy, Billing, Registrar Relations, Marketing and communications, Product and Legal in addition to the technical resources required to physically move the registry back-end.
Following the practical advice above will help reduce the risk of a poor migration experience and ensure selection and migration to a Technical Registry Operator that: is in tune with the Registry's business goals, can plug gaps in Registry Operator's expertise or resources and is a company that the Registry Operator feels that it can do business with over the long term.
About the author
Andy manages marketing for CentralNic Registry. With a wealth of knowledge and experience in the domain name industry, Andy previously held senior roles in product and marketing roles at Famous Four Media (a global registry management company) and NetNames (formerly Group NBT, a leading international registrar).
Andy holds a bachelor's degree in Engineering, a master's degree in Business Administration, is a Chartered IT Professional and a Chartered Engineer.