Production Domain Migration
How I migrated Lok Chan Art to a new domain while preserving payments, email infrastructure, storage, application configuration, and SEO signals.
Published:
Production domain migration
In 2026, I migrated the production application from Sunny Day Art to Lok Chan Art.
The change involved considerably more than replacing a name and logo. The original domain was connected to application configuration, email infrastructure, payment webhooks, storage policies, SEO, and several external services.
Rather than replacing the existing production setup in a single cut-over, I introduced the new domain alongside it and moved the individual parts of the system in a controlled sequence.
EXISTING PRODUCTION
│
│ remains live
▼
sunnydayart.com
│
▼
Vercel project
▲
│
│ introduce & validate
│
lokchanart.com
▲
│
protected Preview
─────── after validation ───────
sunnydayart.com
│
│ permanent redirect
▼
lokchanart.com
│
▼
Vercel project
Parallel migration environment
The new domain was initially connected to a protected Vercel Preview environment.
This allowed me to test the rebranded application with environment-specific configuration without modifying the existing production site.
The migration was verified before the final production cut-over, including:
- checkout and payments
- Stripe webhooks
- secure image uploads
- transactional email
- administrative authentication
- canonical URLs and metadata
This separated verification of the new configuration from activation of the migration. The existing production application could continue operating while the future configuration was tested independently.
Environment isolation
Preview and production configuration were managed separately.
Domain-dependent credentials and URLs could therefore be tested against the future domain before the production environment was changed.
This also provided a relatively simple rollback path during the migration: problems in the new configuration did not require immediately undoing changes to the existing public site.
Storage without unnecessary migration
The existing S3 storage architecture was retained rather than duplicating production assets simply because the public brand and domain had changed.
The important distinction was whether an infrastructure resource actually depended on the public domain.
Brand / domain changes
│
▼
Does this resource depend
on the public domain?
/ \
yes no
│ │
▼ ▼
update preserve
│ │
┌─────────┼─────────┐ ├── S3 buckets
│ │ │ └── existing order assets
▼ ▼ ▼
origins public email
URLs configuration
CORS configuration was extended for the new origin while existing order assets remained in their original storage.
This avoided an unnecessary data migration and preserved historical order data.
The decision also meant that internal infrastructure did not need to mirror a public branding change when there was no technical reason for it to do so.
Email infrastructure
The new domain was configured with Google Workspace and authenticated through the required DNS records.
The Workspace primary domain and account identity were migrated to the new brand while retaining access to addresses from the previous domain where necessary.
Transactional email remained separated from the Workspace mailbox and continued to be handled through Resend.
This kept two different responsibilities independent during the migration: normal business correspondence through Google Workspace and application-generated transactional communication through Resend.
Protected preview webhooks
Vercel Preview deployments were protected by platform authentication, which initially prevented Stripe from delivering webhook events to the preview application.
Removing Preview protection entirely would have made the deployment publicly accessible simply to allow one machine-to-machine integration to reach it.
Instead, an automation bypass was configured specifically for the webhook integration while the rest of the Preview deployment remained protected.
Vercel Preview
┌─────────────────────────┐
│ protected access │
│ │
Browser ───────────►│ authentication required │
│ │
Stripe │ │
│ │ │
│ webhook │ │
▼ │ │
automation bypass ─►│ /api/stripe/webhook │
└────────────┬────────────┘
│
▼
verify Stripe
signature
│
▼
payment workflow
The bypass solved the platform-access problem only. Stripe webhook signature verification remained a separate application-level security check.
This allowed the actual payment workflow to be tested before exposing the new deployment publicly.
SEO-preserving redirects
The previous domain returns permanent redirects while preserving the original pathname.
The migration therefore preserves page-to-page relationships rather than treating the old domain as a single entry point.
sunnydayart.com/en/gallery
│
│ 308
▼
lokchanart.com/en/gallery
sunnydayart.com/de/commissions
│
│ 308
▼
lokchanart.com/de/commissions
sunnydayart.com/en/journal/article
│
│ 308
▼
lokchanart.com/en/journal/article
This preserves the relationship between old and new pages instead of redirecting every historical URL to the homepage.
The redirect itself was only one part of the SEO migration. Signals generated by the application also had to move consistently to the new canonical domain.
lokchanart.com
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
canonical sitemap hreflang
URLs URLs URLs
│ │ │
└─────────────────┼─────────────────┘
│
┌─────────┴─────────┐
▼ ▼
Open Graph structured data
│ │
└─────────┬─────────┘
▼
consistent new domain
│
▼
Google Search Console
Change of Address
Canonical URLs, sitemap entries, metadata, and structured data were updated to reference the new domain.
Both domains were verified in Google Search Console, and a Change of Address was submitted after the permanent redirects had been validated.
Controlled indexing
The new deployment remained noindex, nofollow while the migration was being tested.
Indexing was enabled only after the production configuration, redirects, payments, uploads, email, and administrative functionality had been verified.
The order of operations was intentional:
PREPARE VERIFY CUT OVER STABILIZE
│ │ │ │
▼ ▼ ▼ ▼
new domain checkout canonical domain redirects remain
Preview config uploads permanent redirects active
DNS & email webhooks indexing enabled old domain kept
service config email sitemap updated indexing monitored
admin auth Change of Address
│ │ │ │
└───────────────────┴────────────────────┴─────────────────────┘
existing production protected
until verification
This prevented search engines from discovering a partially configured version of the application while still allowing the complete production behavior to be tested beforehand.
Result
The migration moved the public identity of the application to Lok Chan Art without requiring the underlying production system to be rebuilt around the new brand.
Existing storage and historical assets were preserved, payment and email integrations were validated against the new domain before cut-over, old URLs continue to resolve to their corresponding new locations, and SEO signals were transferred through canonical updates, permanent redirects, and Search Console migration tooling.
The migration also reinforced a broader architectural principle used throughout the project: change the parts of the system that actually depend on the new requirement, and preserve the parts that do not.