Ecommerce replatforming agency

The causes are well known and almost all preventable. Redirects mapped to generic destinations, URL structures changed without a plan, internal linking rebuilt in a way that strands deep pages, structured data not reimplemented, templates that render nothing without scripts, a staging noindex left in place, and a robots file copied across from the build environment. Any one of them can cost months. Together they are why migrations have the reputation they do.

The preparation is a baseline. Before anything is built, we record the pages that earn traffic and revenue, the queries they rank for, the internal link structure, the structured data present, and the template each page uses. That baseline is what makes the post launch period diagnosable, because it turns a vague sense that traffic is down into a specific list of pages that lost position and a reason for each one.

After cutover the work is monitoring rather than waiting. Crawl statistics, index coverage, server log sampling, redirect testing at scale and rank tracking on the baseline set, checked daily at first and then weekly. Most recoverable problems show up within the first two weeks, and most of the sites that never recover are the ones where nobody looked until the monthly report.

The most valuable thing to protect in a migration is item identifier stability. When product ids change, Merchant Center treats every product as new, and the performance history that Shopping and Performance Max rely on starts again from nothing. Where the new platform forces new identifiers, that reset needs planning for rather than discovering, with budgets and targets adjusted for a period of relearning.

The feed itself has to change on the same schedule as the site. Landing page URLs all change at cutover, so a feed still pointing at old addresses produces errors across the whole catalog within hours. The new feed should be prepared in advance, submitted at cutover, and the old feed removed rather than left running, since two feeds covering the same products create duplicates. If the domain changes as well, the site claim and verification have to be redone before the feed is fetched.

During the content freeze the old site is often still live while the new one is being finalized, which is the period where price and availability drift apart. Keeping both in step, or freezing promotions entirely through the window, avoids a wave of mismatch disapprovals in the first days.

Three things break in this channel and all three are fixable in advance. The pixel or dataset should be preserved rather than recreated, because a new one starts with no history. The catalog feed source changes with the platform, and the product identifiers in that catalog have to match the identifiers the pixel sends, or dynamic ads stop matching products to viewers. Website custom audiences built on URL rules that no longer exist quietly stop collecting, so those rules need rewriting for the new structure before launch rather than after somebody notices the audience shrinking.

Creative and landing pages need a sweep too, since live ads pointing at old URLs will be sending traffic to redirects at best. Where the migration is worth mentioning to customers, a short note to the existing list does more good than an ad campaign, particularly if accounts, saved items or loyalty balances have moved.

Customer data moves before anything else in the email platform, and the part that gets missed is consent status. A subscriber who opted in on the old platform has to arrive with that state intact, along with their suppression status, or the store risks sending to people who asked not to hear from it. Purchase history matters just as much, because every flow that segments on what somebody bought has nothing to work with until it lands.

The triggers themselves need rebuilding rather than reconnecting. Cart and browse events, order events and custom properties are all platform specific, so flows that looked fine in the interface can be firing on events that no longer occur. Each one gets tested with a real order after cutover. Transactional templates, which usually live on the platform rather than in the email tool, need their own review, since order confirmations and shipping notices are the most read messages the store sends.