Changing image CDN sounds like a migration and is mostly a rename. The images stay where they are, the markup stays as it is, and what changes is a hostname and the spelling of some query parameters. The risk is not the work; it is doing it all at once and finding out afterwards which of a few thousand URLs now looks different.

First, where are the originals?

Everything else follows from one question: does the service you are leaving fetch your images, or keep them?

  • It fetches them. An imgix web folder source, Cloudinary's fetch delivery, or Cloudflare's transformations on a zone it proxies all read from a server you run. The originals never moved, so there is nothing to move back.
  • It keeps them. Images uploaded to Cloudinary or stored in Cloudflare Images exist, in their original form, only there. They have to be exported to storage you host and serve over HTTPS before anything else can fetch them. Do this first, and keep the export: it is your originals, and it should never again exist in only one place.

This edge only ever fetches. An account names one origin, and the path in a delivery URL is the path there, so /products/sofa.jpg?w=800 means <origin>/products/sofa.jpg, resized.

Run both, side by side

Because nothing is uploaded, the new service can serve every image you have the moment its origin is set, while the old one goes on serving production. There is no warm-up: each rendition is made on its first request and cached. That makes a gradual move possible:

  1. Point the new account at the same origin the old service reads.
  2. Pick a few representative URLs — a product photo, a hero, a thumbnail, anything with a watermark or a crop — and translate them.
  3. Open each pair side by side and compare the pictures and the byte counts.
  4. Move one template, or one section of the site, and watch it for a while.
  5. Move the rest.

The image audit is a quick check for step 3 at page level: it measures what each image on a page weighs now, and what it would weigh re-encoded the way a node does it.

Translating the URLs

Most parameters have a direct equivalent, and for imgix many have the same name: w, h, q, dpr, bri, con and sat carry over unchanged. Cloudinary's path segments become query parameters, and Cloudflare's options become query parameters on the delivery hostname instead of a /cdn-cgi/image/ prefix. The full tables are in the three migration guides: imgix, Cloudinary and Cloudflare Images.

The rows worth reading twice are the ones where the name matches and the meaning does not:

  • Fitting. fit=contain here never enlarges an image smaller than the box. Where your old service's equivalent did enlarge, small originals will now stay small.
  • Scales. blur runs from 0 to 100, and gam is a factor where 1 is unchanged. A value copied across can be much too strong or do nothing.
  • Strengths that became switches. sharpen is on or off, with no amount.
  • Rotation is in multiples of 90 degrees only.
  • Metadata is removed by default; strip=false keeps it.

Things that do not translate

  • Signed URLs use a different recipe, so every signed URL has to be signed again, with a key from the console. A signature from the old service will be refused, not ignored.
  • Named transformations and variants become presets, defined in the console and named in the URL with preset. Anything written in the URL still wins over the preset.
  • Face cropping. ai_crop crops around the most salient subject, which in a portrait is the face; there is no separate face detector, and ai_crop=face is accepted as the same thing.
  • Video and output that moves are not transcoded. Leave those URLs where they are.

The last step is DNS

If your image URLs already use a hostname of your own — img.example.com rather than the old service's — the final move needs no change to markup at all. Add the hostname to the new account (custom domains are on the paid tiers), wait for its certificate, and point the CNAME at it. Until the record changes, the old service keeps answering, which is the rollback plan: change it back.

If the old hostname is written into your pages, use the move to put your own in its place. It is the one change that makes the next migration, from this service or any other, a DNS record instead of a release.