Imgix Migration Checklist: Zero Downtime Cutover

Your engineering team has made the call. You're leaving Imgix.

The pricing model has become unpredictable, the credit pool burns faster than anyone expected every time a new responsive variant rolls out, and LCP keeps showing up in infrastructure reviews as something images are making worse, not better.

The question on the table now is not whether to migrate. It's how to do it without a single production incident.

Broken image URLs do not throw visible errors. They produce silent 404s that stall page loads, drop your Largest Contentful Paint (LCP) score, and quietly remove images from Google Image Search indexing, all without triggering a single monitoring alert.

A poorly sequenced CDN switch can cause exactly this kind of damage. A well-sequenced one takes 2-5 working days and leaves nothing broken.

This is not an evaluation article. It is the operational reference document you run on cutover day.

This checklist is built for the second outcome. It is a production-ready reference document, organized into four discrete phases that you can execute in sequence, hand off to a junior engineer, or run through as a team on cutover day.

, at no point during the cutover, visitors should experience broken, slow-loading, or missing images

Short Answer: What Is an Imgix Migration Checklist?

An Imgix migration checklist is a structured, phase-by-phase reference document that engineers follow to switch from Imgix to a new image CDN without downtime, broken URLs, or Core Web Vitals regressions. It covers four stages: pre-migration auditing, parallel staging environment setup, staged DNS CNAME cutover, and post-migration validation. When followed correctly, the entire process requires no file moves, no URL restructuring, and zero production downtime.

Key Takeaways

Migrating from Imgix does not require moving a single image file. Your origin storage (S3, GCS, or a web proxy) stays exactly where it is.
The migration is a hostname swap staged safely through a DNS CNAME cutover, not a data migration or a URL refactor.
The most common cause of broken images during an Imgix migration is hardcoded URLs in CMS records and template files, not the DNS change itself.
Most migrations from Imgix to Gumlet are complete in 2-5 working days when the Four-Phase Imgix Migration Protocol is followed in sequence.

Before You Start: What a Zero-Downtime Imgix Migration Actually Requires

Zero downtime in an Imgix migration means that, at no point during the cutover, visitors should experience broken, slow-loading, or missing images.

The goal is a seamless handoff from Imgix's delivery hostnames to the new platform's CDN, with no window of failure in between.

Before diving into the phases, there is one framing point that changes everything about how you approach this migration: this is not a file migration. Your images stay where they are, on S3, GCS, or your web proxy origin. Nothing moves. The migration is a hostname swap staged through DNS, and the preparation work determines whether the swap is smooth or chaotic.

Gumlet occupies the same architectural position as Imgix. It sits between your origin storage and your users, fetches images from your existing S3 or GCS bucket, applies on-the-fly transformations through URL query parameters, and serves the output through its multi-CDN layer.

The parameter convention is nearly identical. Most transformation parameters like w, h, fit, crop, q, and dpr map directly. For most stacks, the migration is a hostname change plus an afternoon of careful validation in staging.

You can explore Gumlet's full capabilities and how it compares to Imgix as an image CDN and optimization platform before committing to the migration.

The Four-Phase Imgix Migration Protocol

The structured approach that minimizes production risk breaks the migration into exactly four phases:

Pre-Migration Audit: Before touching any DNS, map every parameter in use, document every location where Imgix URLs are hardcoded, and establish your LCP baseline.
Parallel Environment Setup: Run Gumlet against the same origin on a staging subdomain while Imgix continues serving production.
Staged CNAME Cutover: Shift production traffic with pre-lowered TTL (Time To Live), during a low-traffic window, with immediate monitoring.
Post-Migration Validation: Confirm LCP parity, zero new 404s, correct format distribution, and billing stop on Imgix.

Each phase is a complete checklist below. Work through them in order.

Phase 1: Pre-Migration Audit Checklist

The goal of this phase is to produce a written audit document before touching a single configuration.

Most production incidents during image CDN migrations trace back to something that was not mapped in advance: a parameter that behaves differently, a hardcoded URL that a global find-and-replace missed, or an LCP baseline that was never recorded.

Your image CDN is a direct input into both performance and search visibility and hence, knowing your exact current state before the migration is not optional.

Audit steps:

Pull a representative sample of live Imgix URLs directly from your CDN logs or analytics platform. Search specifically for your Imgix delivery hostname (for example: your-source.imgix.net).
Extract every unique URL parameter actually in use across your codebase. Do not rely on documentation or memory. Pull real traffic data.
Rather than reproducing the full table here, refer to the complete Imgix-to-Gumlet parameter mapping reference for the side-by-side breakdown.

Most-used Imgix parameters and their Gumlet equivalents

Imgix parameter	Gumlet equivalent	Notes
w	w	Identical
h	h	Identical
fit	fit	Identical
crop	crop	Identical
q	q	Identical
dpr	dpr	Identical
auto=format	f=auto	Gumlet uses the f parameter
blur	blur	Identical
sharp	sharp	Identical
flip	flip	Identical
rot	rot	Identical
bg	bg	Identical
fm	f	Different parameter name
txt	No equivalent	Use Gumlet's canvas overlay — plan a workaround in Phase 1
palette	No equivalent	Plan a workaround or drop
blend	No equivalent	Plan a workaround or drop
bg-remove	No equivalent	Plan a workaround or drop

For the complete parameter reference, see Gumlet's image transformation docs.

Flag any Imgix-specific parameters without a direct Gumlet equivalent, such as AI-powered background removal, palette extraction, or watermark composition. These need planned workarounds before cutover, not workarounds discovered in production.
Record your current LCP baseline for your five most image-heavy pages using Google PageSpeed Insights. Save screenshots. You cannot confirm a successful migration without pre-migration numbers to compare against.
Run Gumlet's free Website Image Analyzer on your current Imgix-served pages and save the report. This gives you a format distribution, compression baseline, and alt text coverage snapshot to compare post-migration.
Identify every location where Imgix URLs are hardcoded: template files, CMS database records, markdown files, React component strings, and environment configs. A CNAME change in DNS does not touch any of these locations. This is the most overlooked risk in any Imgix migration.
Verify that your origin storage is accessible and that bucket permissions are documented. Confirm the exact S3 bucket name, GCS bucket, or web proxy URL currently configured in your Imgix source.
Note your exact current Imgix subdomain as it appears in production (for example: your-source.imgix.net). You will need this for the find-and-replace step in Phase 3.
Align the cutover window with all relevant stakeholders. Define a low-traffic slot and ensure the on-call engineer is available for at least 2 hours post-switch.

Phase 2: Parallel Environment Setup Checklist

Running Gumlet in parallel on a staging subdomain before touching production DNS is not optional. It is the step that turns a risky cutover into a controlled validation with real comparison data.

Teams that skip this step and go straight to a production DNS change are the ones who discover unsupported parameters, format parity gaps, and misconfigured origins during peak traffic.

AVIF usage on the web grew 386% between 2022 and 2024, according to the HTTP Archive Web Almanac 2024, which means format delivery is more critical now than it was even two years ago. Verifying that your new CDN delivers WebP and AVIF correctly in staging is not a nice-to-have.

Setup steps:

Create your Gumlet account and connect it to the same origin storage as your current Imgix source. There is no need to move, copy, or re-upload any image files.
Configure your S3, GCS, or web proxy origin in Gumlet's dashboard using the exact same bucket URL or proxy path currently used by Imgix.
Test a representative image from each distinct URL pattern in your codebase through the Gumlet staging endpoint. Cover every pattern type: resized images, cropped images, format-converted images, and responsive variants.
Confirm WebP and AVIF format delivery on test images. Compare the output visually against Imgix-served equivalents for quality parity. Check file sizes side-by-side.
Create a staging subdomain (for example: images-staging.yourdomain.com) and configure its CNAME to point to your Gumlet delivery hostname. Do not point your production subdomain to Gumlet yet.
Run your five highest-traffic pages through both staging (Gumlet) and production (Imgix) and compare LCP scores, file sizes, and visual output. Document both sets of numbers.
Validate that unsupported parameters fail gracefully. Pass a parameter that Gumlet does not support and confirm the image still serves correctly, without that transform applied, rather than returning a 404 or an error.
Set up Gumlet's analytics dashboard now, before production traffic begins, so the monitoring baseline starts from day one of the production cutover.

Phase 3: Staged CNAME Cutover Checklist

The difference between a big-bang cutover and a staged one is the difference between a production incident and a routine infrastructure change. The staged approach pre-lowers TTL, picks a low-traffic window, and keeps Imgix running as a fallback. None of that takes long to set up, and all of it is worth doing.

Cutover steps:

Lower the TTL on your production image CNAME record to 300 seconds (5 minutes) at least 24 hours before the scheduled cutover. If TTL is still at its default value (commonly 3,600 to 86,400 seconds) at the moment of the switch, stale DNS will persist for hours after you update the record, meaning a significant share of your visitors will continue hitting Imgix.
Schedule the cutover during a confirmed low-traffic window. Avoid peak hours, ongoing paid campaigns, product launches, and any high-traffic events in the surrounding 48 hours.
Update the CNAME record for your production image subdomain to point to your Gumlet delivery hostname.
Monitor immediately for the first 15 minutes: watch for 4xx error spikes in your CDN logs, check your client-side error tracking, and verify your most-used Imgix URL patterns are resolving correctly.
Visually inspect your five most image-heavy pages. Open them in Chrome DevTools, verify images load, and check the Network tab for any failed image requests.
Confirm LCP on your most critical page has not regressed. A quick Google PageSpeed Insights run takes 60 seconds.
If your application constructs image URLs from an environment variable or config value, update the hostname in that config and redeploy. This is a cleaner path than a DNS change for config-driven stacks and requires no CNAME update on your production subdomain.
If image URLs are hardcoded in template files, run a global find-and-replace substituting your Imgix hostname with your Gumlet delivery hostname. Test the pattern on one file before running it across the repo.
For image URLs stored in a CMS database, run a targeted find-and-replace query. Always test this on a staging database copy first, then apply to production.
Keep Imgix active and do not cancel the account for at least 48-72 hours post-cutover. The rollback option is worth the cost of two days of parallel billing.

Phase 4: Post-Migration Validation Checklist

The validation phase is what closes the migration officially. It produces the documented evidence that LCP held, no 404s appeared, format delivery is correct, and Imgix billing has stopped. Without this phase, you have a migration that probably worked, not one you can confirm worked.

Validation steps:

Re-run Google PageSpeed Insights on your five most image-heavy pages and compare LCP before and after migration. Document both numbers. A Gumlet migration should maintain or improve LCP through multi CDN delivery and automatic AVIF/WebP output.
Re-run Gumlet's Website Image Analyzer and compare format distribution, compression savings, and alt text coverage against your pre-migration baseline report from Phase 1.
Check Google Search Console coverage for any new 404 errors on image-heavy pages in the 48 hours after cutover. Filter by the date of your cutover and look for any crawl anomalies.
Review Gumlet's analytics dashboard: confirm cache hit ratio, WebP/AVIF format distribution, and bandwidth usage over the first 48 hours. These numbers should reflect the traffic patterns you validated in staging.
Verify responsive image variants are serving correctly across screen sizes. Use Chrome DevTools device emulation to test mobile viewpoints against your most image-heavy templates.
Verify that any signed URL patterns or access-controlled image routes still behave correctly in production.
Confirm your Imgix account is no longer accruing new charges. Check your Imgix billing dashboard after the 48-72 hour buffer.
Remove the Imgix CNAME from your DNS after 7 days of clean operation if no issues surface.
Document the completed migration in your infrastructure runbook: include the cutover date, your Gumlet delivery hostname, any parameter adjustments made, and the before/after LCP numbers.

Image CDN Comparison: Gumlet vs. Imgix vs. ImageKit

If you are still finalizing your destination platform before running this checklist, the table below covers the factors most relevant to a production migration.

Feature	Gumlet	Imgix	ImageKit
Origin compatibility	S3, GCS, Web Proxy, Azure	S3, GCS, Web Proxy	S3, GCS, Web Proxy
Migration path from Imgix	Documented, parameter-mapped	N/A	Documented
Parameter syntax parity	Near-identical (query string)	N/A (reference)	Path-based and query string
CNAME cutover support	Yes	Available for Enterprise Plans	Yes
Multi CDN delivery	Yes	No (single CDN)	No (single CDN)
WebP and AVIF auto-delivery	Yes	Yes	Yes
Pricing model	Bandwidth-based	Credit pool (shared)	Bandwidth-based
Analytics dashboard	Built-in, image-level	Limited	Basic
Unsupported params behavior	Silent discard (no broken images)	N/A	Silent discard
Support response time	24/7 live chat, email, calls	Email (hours to days)	Email and chat

For teams evaluating Gumlet against Imgix before committing to a migration, Gumlet's Imgix alternatives comparison covers pricing model analysis and real workload benchmarks in depth.

Common Reasons Imgix Migrations Break Production

Each failure mode below is preventable. All of them trace back to something that was not mapped during the Phase 1 audit or a step that was assumed rather than verified before the cutover window opened.

Hardcoded Imgix hostnames in CMS records

A DNS change updates where new requests resolve. It does not update database-stored image URLs. Any image URL saved directly in a CMS record with the Imgix hostname will continue pointing at Imgix after cutover until a database find-and-replace is run. This is the single most common source of broken images post-migration.

Imgix hostnames in markdown files or static site generators

If your documentation, blog content, or marketing site is built from a Git repository with markdown files, grep the entire repo for your Imgix delivery hostname before cutover. These files are frequently missed in a standard template find-and-replace.

TTL not pre-lowered

If your CNAME TTL is still at 86,400 seconds when you update the DNS record, DNS resolvers around the world will continue serving the old record for up to 24 hours. Pre-lowering TTL to 300 seconds at least 24 hours in advance is the single most impactful preparation step you can take.

Unsupported parameter assumptions

Parameters like txt=, palette=, or blend= that exist in Imgix and are not supported in Gumlet are silently dropped. Images still serve, but if your design relies on those transforms for visual output, you need mapped substitutes identified in Phase 1, not discovered in production.

React or JavaScript component strings

Frontend code that constructs image URLs as string literals may reference the Imgix hostname in a way that a global find-and-replace pattern misses if the search is too narrow. Test your replacement against a representative set of generated URLs, not just template files.

Skipping the 48-72 hour fallback buffer

Canceling Imgix immediately after cutover eliminates your rollback option. The cost of two days of parallel billing is negligible compared to the cost of a production incident without a recovery path.

Frequently Asked Questions About Migrating from Imgix

1. Can I migrate from Imgix to Gumlet without re-uploading any image files?

Yes. Gumlet connects directly to your existing origin storage, whether that is Amazon S3, Google Cloud Storage, or a web proxy, in exactly the same way Imgix does. There is no file move, no duplication, and no re-upload required. The migration is a hostname change and a configuration setup, not a storage migration.

2. How long does a typical Imgix migration take for a production website?

Most engineering teams complete the migration in 2-5 working days. The Phase 1 audit and Phase 2 parallel setup consume most of that time. The Phase 3 CNAME cutover itself typically takes under an hour when the TTL has been pre-lowered 24 hours in advance. Teams with a custom domain abstraction already in place tend toward the shorter end of that range.

3. Will switching from Imgix affect my Core Web Vitals or LCP score?

Switching to Gumlet should not cause an LCP regression. In most cases, Gumlet's multi-CDN delivery and automatic AVIF and WebP output maintain or improve LCP compared to a standard Imgix configuration. The critical step is establishing a Google PageSpeed Insights baseline in Phase 1 and verifying against it in Phase 4. Do not assume the migration worked without documented before-and-after numbers.

4. What happens to Imgix parameters that Gumlet does not support?

Unsupported parameters are silently discarded. The image is still served with all supported transformations applied. Nothing breaks. The Phase 1 audit exists precisely to identify any parameters in this category before they reach production, so you can decide whether a workaround is needed or whether the transform can be safely dropped.

5. Do I need to rewrite how my application constructs image URLs when switching from Imgix?

For most stacks, only the hostname changes. If your application constructs image URLs from an environment variable or config value, update the hostname there and redeploy. If URLs are hardcoded in templates, run a find-and-replace on the Imgix hostname. The query-string parameter syntax is nearly identical between Imgix and Gumlet, so most transformation logic requires no rewriting.

6. Can I run Imgix and Gumlet at the same time during the migration?

Yes, and this is the recommended approach. Because both platforms can be assigned to different subdomains, you can route a staging subdomain through Gumlet while production continues on Imgix. This is exactly what Phase 2 of the Four-Phase Imgix Migration Protocol specifies. Once performance and format delivery metrics hold up on the Gumlet-served staging environment, the production CNAME cutover in Phase 3 becomes a low-risk operation.

What to Do After the Migration is Complete

The Four-Phase Imgix Migration Protocol turns what most teams fear as a high-stakes cutover into a routine infrastructure change: audit first, validate in staging, shift DNS in a low-traffic window, then confirm everything held.

The key insight that makes this achievable in days rather than weeks is that this is a hostname change, not a data migration. Your images never move.

Once validation is complete and Imgix billing has stopped, use the Gumlet analytics dashboard to review your first 30 days of post-migration data. Look for cache hit rate trends, format distribution improvements, and any bandwidth savings that your finance team will want to see in the infrastructure review.

If you want to establish your performance baseline before even starting the migration process, Gumlet's free Website Image Analyzer runs a full image audit against your current Imgix-served pages in under 60 seconds.

It gives you the format compliance, compression levels, sizing data, and LCP signals you need to walk into Phase 1 with a complete picture.

When you're ready to configure Gumlet against your origin and start running the parallel staging environment from Phase 2, check Gumlet's image CDN pricing to understand the bandwidth-based model before your first invoice.

If you want a guided walkthrough from the Gumlet team before touching production, schedule a demo and bring your current Imgix usage data. They will map your workload to Gumlet's delivery model and confirm there are no surprises waiting.