GeekyAnts migrated one of India’s largest banks from .com to .in during a code freeze

Background Information: On February 7, 2025, the RBI mandated that banks migrate to the new domain framework before the October 31 deadline. The bank’s internal release policy restricted major changes until after Diwali in October, compressing the execution timeline. Here’s how the migration was delivered on time — without disrupting a single transaction.

During the domain change window set by RBI, our client processes crores of transactions daily. Traffic is at its annual peak. Any disruption means direct revenue loss, not a degraded experience. The bank had two options: miss the regulatory deadline or risk the busiest trading period of the year. Neither was acceptable.

Getting the exception approved

A code freeze is a commitment. To get one approved at a bank of this scale, you need to demonstrate that the change carries less risk than leaving it undone.

The GeekyAnts team initiated a formal Change Request process and secured approval to proceed — on one condition: zero disruption to the festive sales window. That condition became the governing constraint for every decision that followed. The approval also set the deployment window: no work during business hours. All execution had to happen in off-peak maintenance slots.

Discovery before the freeze started

Before the freeze locked down changes, the team ran a full discovery phase. The goal was to eliminate unknowns before the clock started.

This produced two outputs:

• A full audit of 100+ external partner integrations and their domain dependencies.
• Domain segmentation: specialist teams assigned to critical product areas such as the Loans Expressway, where user journeys had unique architectural dependencies that a generic migration approach would have broken.

This phase existed because surprises during a nocturnal deployment, with no room to roll back during peak festive traffic, are not recoverable.

2 AM deployments and what they covered

All switchovers ran between 2:00 AM and 5:00 AM. Teams worked through the night in a 24/7 virtual war room, monitoring DNS propagation in real time as each change went live.

The technical scope covered five categories:

What changed during the migration windows

• Backend microservices: environment variables and base URLs updated to reference the .in domain.
• Infrastructure: Ingress rules updated to accept .in traffic into the pods. SSL/TLS certificates are provisioned to prevent browser security warnings.
• Firewall layers: WAF rules updated across AWS WAF, Nginx, and Palo Alto to allow traffic from the new domain.
• CDN and cache: old .com references purged. CDN reconfigured to serve exclusively from the .in origin — required to ensure Diwali offer pages served accurate, fresh content.
• SEO continuity: 301 redirects implemented from .com bookmarks and indexed URLs to .in equivalents. CORS policies updated to allow API calls from the new domain.
• Identity systems: Keycloak and internal email infrastructure migrated to .in.

The trust problem: telling customers before they notice

Before the technical cutover, the Sales and Product teams ran a pre-emptive communication campaign across email, SMS, and in-app pop-ups. The message was simple: the address is changing, your bank is not. This ran in the weeks before the migration went live, so customers who saw the new URL had already been told to expect it.

The 301 redirects handled customers who missed the communication. Old URLs continued working. Search rankings were preserved.

What the migration actually required

A domain migration at a consumer bank is a coordinated update across infrastructure, security, content delivery, identity, SEO, and customer communications — sequenced to produce zero customer-facing disruption.

The code freeze added a constraint that forced every decision to be made in advance. There was no room to discover a missed WAF rule at 3 AM during Diwali week. The discovery phase and the segmentation of teams by domain were the risk controls that made the nocturnal execution possible.

As a result, the bank met its RBI compliance deadline. No customer transaction was interrupted during the festive period. The domain change was invisible to end users.

Three things that made this work

1. Discovery before the constraint hit

The 100+ partner audit and the domain segmentation happened before the freeze. By the time the deployment windows opened, there were no unknowns left in the scope.

2. The deployment window as a forcing function

Working in 3-hour nocturnal windows with no room for incident response concentrated the team’s planning. Every step was scripted, every rollback condition defined, before the first change went live.

3. Communication ran ahead of the technical change

The trust risk of a domain change is as high as the technical risk. Running the customer communication campaign weeks before the cutover meant that by the time the .in domain went live, customers had already been prepared for it.

About this Project

The migration was executed by GeekyAnts in partnership with the bank’s internal engineering and compliance teams. The work spanned infrastructure, security, CDN, identity, and product communications. If you are working through a comparable constraint — regulatory deadline, legacy system dependency, or a change that cannot go wrong during a peak period — the approach documented here is one we have tested and delivered under production conditions.

Interested in bringing on similar innovation to your company? Talk to our consultants today. CLICK HERE