Overview
In May 2025, Tucows Registry Services completed the largest domain migration in history*—executed in record time, without service disruption, and with all domains remaining continuously active.
In 2024, the National Internet Exchange of India (NIXI)—operator of .in and related IDN extensions—opened a multi-stage RFP process to select a new technical services provider (TSP). The stakes were national-scale: 4.2M+ domains, ~9M contacts, 140 extensions, and support for its 15 IDN TLDs, as well as new safety and performance capabilities specific to India’s linguistic and operational needs.
Selection was by a government tender process with a rigorous evaluation and strict standard requirements. They were seeking a trusted provider with proven experience, reliability, and the capabilities to meet their immediate needs and support their long-term objectives. Tucows Registry Services was selected based on the evaluation of its capabilities and commercial proposal.
In May 2025, Tucows Registry Services completed the largest domain migration in history*—executed in record time, without service disruption, and with all domains remaining continuously active. With weekly rehearsals, automation, and a two‑phase cutover plan, we reduced the registry freeze to less than 6 hours—and our cutover portion to approximately 4 hours—safeguarded DNS continuity, and delivered measurable post‑migration efficiencies. Along the way, we shipped new platform features—including DNS fold‑into publishing and IDN contextual validation for 23 IDN tables— implemented without any process or DNS changes for NIXI and their registrar partners.
Tucows Registry Services was selected for meeting its comprehensive criteria — proven experience, financial strength, and a clear commitment to invest in Indian infrastructure, people, and the long-term success of the .in registry. Below, we detail how we approached the solution design and migration, including the technical planning, platform adaptations, DNS architecture, registrar onboarding, and operational lessons for RSPs planning large-scale migrations.
At a glance
Scope
4.2M+ domains; ~9M contacts; 140 extensions total
Cutover window
≤ 6 hours freeze; ~4 hours Tucows Registry Services cutover
IDN safety
Contextual validation live for 23 IDN tables (since May 28)
Zones publishing
All NIXI zones generated, signed, and published in ~28 seconds
The challenge
NIXI needed a solution for their unique reality: A registry system and an EPP that supported critical online services, complex naming rules across 23 IDN tables, and a varied client base including both global and local registrars.
Several factors raised the complexity of the migration and broadened the scope of the project:
A huge dataset
Migrating NIXI would mean transferring and validating over 4.2 million domains and nearly 9 million associated contact records. We would need to review and optimize our migration procedures and data processing pipelines to ensure both a fast migration and efficient registry operations.
Critical infrastructure
This was also a migration of a critical service – any interruptions could affect access to government portals, healthcare, public safety, and commerce for hundreds of millions of people.
Unique DNS architecture
NIXI operates 140 zones. These include the .in TLD itself, 15 IDN TLDs, and second-level domains like bank.in. Each zone is a unique namespace where names can be registered, but they are grouped using only 27 parent zones published in the DNS. For example, domains registered under bank.in are published directly under the .in zone, instead of a delegated second-level zone. We needed to build a feature to support this atypical architecture.
IDN complexity
India has 23 languages, including right-to-left scripts, and NIXI employs advanced contextual validation rules to block visually confusable or linguistically invalid labels that could translate into deceptive or unusable domain names. We'd need to integrate NIXI's existing Java-based library into our Python- and Go-based tech stack.
NIXI's partners include global ICANN‑accredited registrars, local registrars authorized within the .in namespace, and operators within the Indian government. To ensure successful registrar onboarding, we needed to understand and accommodate the varying processes and expectations of stakeholders from across all three groups.
Localization and compliance
As is the case with many ccTLDs, NIXI needed the registry service provider to accommodate local regulations around its invoicing, taxation, and data processing. To meet compliance requirements, we'd need to deploy infrastructure within India, invest in local presence and support, and provide invoicing integrated with India's government portal.
Migration of the NIXI website
We would need to take over and operate NIXI’s public-facing website, a critical service channel used by registrars and end-customers, which had been developed and maintained by their previous provider. We'd need to learn an unfamiliar application, integrate it with our systems, and ensure it remained stable during the transition.
Key objectives
Deliver a smooth, predictable migration, minimizing registry freeze and avoiding any post‑cutover incidents.
Preserve and improve DNS performance
Maintain IDN safety across 23 IDN tables using contextual validation rules.
Onboard registrars ahead of cutover to avoid any day‑of surprises.
Ensure compliance by satisfying Indian regulatory and invoicing requirements
Integrate and operate the NIXI website without disruption
Our Approach
Deliver a smooth, predictable migration
Transferring a data set of 4.2 million domains and approximately 9 million contact records is a significant undertaking. Importing it all at once on migration day would likely take upwards of 6 hours, and we wanted to keep our maintenance window to under 4.
Minimizing the timeframe of a freeze is critical for three key reasons:
Business continuity
Registrars and registrants rely on timely updates; freezes block transfers, renewals, and new domain creations.
Operational risk
Long freezes create backlogs and complexity; shorter freezes mean smoother, safer migrations.
Trust
Registrars and customers expect near real-time reliability; extended freezes erode confidence.
For context, a previous migration involving fewer than two million domains required 24–48 hours before operations were fully restored — underscoring the scale and efficiency of this effort.
So we designed a two-step process where we would:
Complete a full import the day before
We brought over all registry data to our system and validated it in advance.
Complete an incremental update on migration day
We repulled from the incumbent registry and applied only the changes made to the data in the last 24 hours.
Ensuring data integrity
This process was not as straightforward as it might sound. We quickly discovered that relying on “last updated” timestamps alone wasn’t sufficiently reliable. Some records could change without the date field being refreshed, creating the risk of inconsistencies in the migrated dataset.
To ensure data integrity, we did two things:
We built tooling that compared every record line by line.
Any difference from the day-before import was flagged and updated, ensuring that no change, however small, was missed. With this approach, we could be confident that the data we carried forward was complete and accurate, while still meeting our goal of a tightly controlled four-hour migration window.
We coordinated closely with the incumbent registry.
Multiple rounds of data exchange and feedback were needed to identify and correct anomalies in the source data. While this back-and-forth added effort, it was essential to improving the overall quality of the dataset and avoiding downstream issues.
Rehearsals
Once our data comparison tooling was in place, we began running weekly rehearsals over the span of six weeks. Each rehearsal was an opportunity to refine the process, improve performance, and uncover edge cases before they could cause problems.
By the time migration day arrived, every step had been timed and tested, and we had rehearsed to the point where the cutover felt routine and could be confident in meeting our goal of a registry freeze under 6 hours. The first two hours were managed by the previous Registry Service Provider, during which they initiated the freeze and generated the transition dataset. The subsequent four hours were dedicated to our transition-day activities: uploading the differential data, validating its accuracy, performing quality assurance checks, and finally reopening the registry to registrars.
Preserve and improve DNS performance
Protecting the integrity of India’s DNS during and after the migration was just as important as moving the registry database. We needed to ensure NIXI's 125 namespaces remained stable and secure throughout the transition.
Adapting to NIXI's existing DNS architecture
NIXI has a unique DNS namespace layout, wherein 140 distinct second-level domains (SLD) are organized below 27 top-level (TLD) zones published in the DNS. Normally, every SLD would have a separate delegated zone to publish registrations under the particular namespace. In NIXI's case, registrations under several second-level namespaces don’t go to a dedicated zone, its records being “folded” into a larger parent zone instead. For instance, records under SLD bank.in are folded into the parent zone .in, instead of having a dedicated bank.in zone file.
Tucows Registry Services’ platform only supported the classic zone delegation model out of the box. A hybrid model was engineered as a new per-SLD “fold-into” feature. This not only preserves the existing behavior NIXI expected, while affording extra flexibility when dealing with hundreds of small SLDs, but also avoids the complexity of operating several hundred extra registry DNS zones for generation, distribution, and DNSSEC delegation.
Ensuring a seamless DNS transition
We worked with the incumbent provider to transition authority from their nameservers to our own, following a tried and true process that guarantees service continuity. It started by sourcing the data for all of NIXI’s 140 zones, republishing to our Anycast DNS network, and then preparing the zones for a seamless DNSSEC transition. It continued with a coordinated handoff so that ROOT delegations flipped only after both systems were aligned, ensuring resolvers worldwide always had a valid path. It concluded with a fresh set of zones being generated and signed from our system, their contents compared to the last zone produced by the incumbent, before publishing to our nameservers.
Operational redundancy through partnership
Our DNS Anycast network spans more than 350 proprietary and partner nodes across five continents. Working with a partner gives us two independent networks, allowing us to improve resilience at both the infrastructure and operational levels, and expand our footprint. This gave us confidence that the switchover could be executed smoothly, with resolvers around the world always finding a fast, reliable path. Beyond the migration day itself, it also gave us confidence that we could support a registry as large and critical as .in.
Strengthening DNS security and performance
In the months following migration, we completed a DNSSEC key rollover and modernized the signatures and algorithms used across NIXI's zones. NIXI's zones to move reduced the size and processing cost of signed responses–improvements that translated directly into faster response times and lighter-weight operations across NIXI’s zones.
Maintain IDN safety
With .in supporting 23 languages, we needed to maintain strong safeguards to prevent confusing or abusive domain registrations. NIXI had an existing solution: a Java-based library of contextual validation rules that would define, for example, which characters were allowed to appear together and how right-to-left scripts must be handled.
Integrating NIXI's solution with our systems
Python- and Go-based tech stack. Rather than attempt a risky rewrite of NIXI's Java-based library, we built a compatibility layer so our platform could call this library to automatically validate domain names at the time of registration. This preserved NIXI’s proven logic while ensuring seamless integration into our system.
Onboard registrars ahead of cutover to avoid day‑of surprises
NIXI’s registrar ecosystem is diverse. It includes global ICANN-accredited registrars, local India-only registrars authorized within the .in namespace, and in-house government or institutional operators. Across registrars, there were different ways of working and integrating the registry.
We prioritized the registrars with the largest domain portfolios
These partners were onboarded first to ensure that the majority of names under management would be ready well before migration day. For smaller or slower-to-respond registrars, we created a structured set of follow-ups, reminders, and monitoring to help them be ready for the migration.
Local communication and hands-on workshops
Ensuring compliance
Beyond the technical challenge of migration, success depended on meeting India’s legal, regulatory, and operational requirements — ensuring the .in registry was fully compliant while remaining accessible and reliable for local stakeholders. Tucows Registry took the following measures:
Data localization requirements
Deployed servers and infrastructure within India
Ensured sensitive registry data remained in-country, meeting government mandates
Reduced latency for Indian registrars
Business presence and invoicing
Established a registered business unit in India
Integrated billing with the government’s GST/e-invoicing portal
Achieved rapid compliance with local tax regulations
Legal and regulatory alignment
Collaborated with NIXI to align operations with government policies for .
in
Adapted processes and contracts to local laws and auditing standards
Built local support capacity within India
Delivered registrar assistance in preferred languages and familiar channels
Integrate and operate the NIXI website
Tucows Registry Services took responsibility for NIXI’s public-facing website — a critical service channel for registrars and end customers. The goal was continuity on day one and greater flexibility for the future.
Seamless takeover
Assumed responsibility for the live site with no downtime
Stabilized and improved a codebase inherited from the previous provider
Deep integration
Connected the website to Tucows Registry Services’ registry systems for domains and payments
Ensured alignment between the backend and the customer-facing portal
Ongoing operations
Took on long-term responsibility for maintaining and enhancing the site
Applied monitoring and performance improvements for stability and reliability
Replaced the constraints of the previous RSP with a more adaptable platform
Enabled faster updates and the addition of new features
Why it mattered
The website is the front door for India’s domain ecosystem
By ensuring continuity and creating room for future improvements, Tucows Registry proved it could be more than a backend provider — a trusted partner in NIXI’s digital presence
Learnings
Own the stack; move fast while maintaining safety.
100% platform ownership + experienced team = rapid, low‑risk customization.
Minimize ecosystem change.
Introduce features (fold‑into, contextual validation) that match the real world rather than forcing policy or delegation churn at launch.
Rehearsals reduce risk.
Weekly, full‑path rehearsals with the operator produce a predictable, compressed cutover.
Communications are infrastructure.
Using the channels registrars actually read (WhatsApp) matters as much as code on the day.
Separate concerns.
Migrate first, then do key rollovers/algorithm upgrades once the system is stable.
Interested in a similar migration?
We’ll tailor a plan for your policy, DNS topology, IDN requirements, and registrar landscape—then rehearse until launch day is uneventful.