We Moved ekyatech.com Off WordPress. Here's What Actually Changed.

We tell SME clients to move off WordPress all the time. Until a few months ago, ekyatech.com itself was still on it. That felt increasingly dishonest, so we fixed it — and since the whole thing is now live, here's exactly what changed, with the actual DNS records and response times instead of the usual "Next.js is faster, trust us."

What the old setup actually was

ekyatech.com was running on WordPress.com hosting. Checking the DNS zone before the switch, the apex domain had two A records:

Type	Value	Owner
A	192.0.78.190	Automattic, Inc. (US)
A	192.0.78.236	Automattic, Inc. (US)

Both IPs resolve back to Automattic — WordPress.com's parent company — registered in the US. There were also CNAME records for wpcloud1._domainkey and wpcloud2._domainkey (email authentication tied to WordPress.com's mail service) and a TXT record for _domainconnect pointing at public-api.wordpress.com, which WordPress.com uses to let its own dashboard silently manage your DNS. None of that is unusual — it's exactly what a WordPress.com-hosted domain looks like. It's just infrastructure that has nothing to do with serving your site fast to a visitor in Delhi or Gurugram.

The surprise: the nameservers were already pointed at Vercel

Here's the part we didn't expect. WordPress.com's own DNS panel showed a banner: "Your domain is using external name servers — these records won't take effect." The actual authoritative nameservers for ekyatech.com were already Vercel's, from an earlier, half-finished migration attempt.

That turned a scary "change nameservers and pray for 48 hours of propagation" migration into something much smaller: connect the domain to the right Vercel project, delete the two stray Automattic A records, done. No registrar login, no waiting on DNS propagation in the usual sense — the DNS zone we needed to edit was already ours. If you're not sure who your actual nameservers are, check before you assume you need a full registrar-level cutover. You might already be closer than you think.

What the new setup is

The new ekyatech.com is a fully static Next.js site: every page is prerendered at build time and served as plain HTML from Vercel's edge network, including a node in Mumbai (region code bom1). Checking it live, right now:

• Time to first byte: ~130ms
• Cache status: x-vercel-cache: HIT — served straight from the edge, no origin round-trip
• Server-side work per request: zero. No PHP, no MySQL query, no plugin stack sitting between a visitor and the HTML

We didn't run a paid PageSpeed API check for this post — the public quota was exhausted the day we wrote it — but the infrastructure facts above are independently verifiable by anyone: run curl -svo /dev/null https://ekyatech.com yourself, or check DNS history for the domain. We'd rather show you what to verify than hand you a screenshot to trust.

Why this is also a lesson for the redirect we had waiting

While we were in there, we also finished connecting dokya.ekyatech.com — a subdomain that used to run as its own separate Vercel project — to this same one. That subdomain redirect to ekyatech.com/products/dokya had actually been sitting in our next.config.ts for weeks, written and ready, waiting specifically for this DNS work to happen. The lesson: if you know a migration is coming, write the redirect logic before the DNS is ready, not after. It turns "migration day" into "flip the domain and watch the code you already wrote just work."

If your site is still on WordPress

Checking whether your own site is in a similar spot takes about five minutes: look up your domain's DNS records, and separately run it through PageSpeed Insights. If your nameservers are stuck at your host and your mobile score is in the 30s or 40s, that's not a WordPress problem specifically — plenty of WordPress sites are fast — it's usually a shared-hosting-plus-plugin-stack problem. Tell us about your current site and we'll tell you honestly whether a migration is worth it, including the cases where it isn't yet.