Move your website with a plan for the details

Decide what moves before rebuilding it

A migration starts with an inventory. We review pages, images, downloads, forms, products, and integrations, then agree what to keep, merge, rewrite, or retire. We also identify who edits the site and what they need to do without calling a developer.

For a store, the scope should name the records involved: products, variants, collections, customers, and order history. We check export access and destination support before promising a transfer. Passwords, subscriptions, gift cards, and app-specific fields need explicit investigation. Anything that cannot move as requested gets a documented alternative before launch.

Typical moves and the work behind them

You can bring us a chosen destination or ask for paid discovery to compare options. These are examples of tasks we can scope, with the exact transfer method decided after inspecting the source.

• WordPress to Shopify: rebuild the storefront, map useful articles and landing pages, and check which editorial features must remain.
• WooCommerce to Shopify: map product variants and SKUs, trial the agreed data import, and test checkout, shipping settings, and payment connections.
• Wix to WordPress: rebuild page layouts and reusable content, move media, and set up editing around the way you maintain the site.
• Squarespace to Shopify: move the agreed catalog and content, rebuild navigation, and account for forms and mailing-list connections.
• A move to Webflow or a custom build: define content structures, rebuild templates, and reconnect the APIs or business tools the site depends on.

Make search preservation part of the scope

If your brief is to migrate a website without losing SEO, we turn that objective into specific checks. We inventory existing page addresses and review available search and analytics data to identify priority pages. We record titles, descriptions, headings, internal links, and relevant structured data for comparison with the replacement.

We map changed addresses to relevant destinations and implement 301 redirects where appropriate. The launch checklist includes checking for redirect chains, broken links, missing pages, canonical tags, sitemap changes, and indexing restrictions left over from staging. Retired content needs an intentional decision, too.

Search traffic staying exactly the same is not something we can promise. We agree which pages and signals to monitor after launch, who investigates issues, and how long that follow-up work is included.

From first email to a controlled launch

After your first email, we clarify the reason for moving, the deadline, and the access available. We inspect the source and propose a scope with deliverables, exclusions, responsibilities, and acceptance checks. Where the unknowns are substantial, paid discovery comes first.

We build and trial imports in a separate preview environment. You review representative pages and records before the full transfer. Checks cover record counts, selected field values, images, mobile layouts, forms, and any purchase flow in scope.

Before launch, we agree a content freeze or final update process, backups, domain access, and a fallback plan. After switching over, we repeat the critical checks on the live site. Handoff includes the agreed source files or repository, editing notes, redirect mapping, and outstanding items with named responsibilities.

Tools chosen around the source and destination

We work with WordPress, WooCommerce, Shopify, Webflow, Squarespace, and Wix. For custom web apps, our stack includes Next.js, React, and TypeScript. The destination should fit the editing workflow and required functionality; choosing it is part of scoping.

The migration plan can include platform exports and imports, CSV field mapping, API transfers, or custom scripts. We select the method after checking access and data structure. Redirect configuration, browser checks, and search monitoring belong in the plan alongside the build. Any required paid tools or platform subscriptions are identified in the scope.

Who this suits, and what to prepare

This suits an owner outgrowing a site builder, a marketer who needs a different editing workflow, or an agency looking for help with part of a migration. We take sub-projects and fix-it jobs on sites we did not build. We take on a small number of projects at a time, with direct contact with the people doing the work.

A full move may be unnecessary if the problem is a broken form or a slow template. We can scope a fix instead. For a migration, prepare the following; missing information can become a discovery task.

• Current platform, proposed destination, and the reason for changing.
• Required features, integrations, and records that must be retained.
• Available exports and access owners for hosting, domains, and analytics.
• Launch constraints, content reviewers, and the person approving handoff.

Our own products are the proof we can show

We design, build, and maintain our own products end to end, including nine apps live on the App Store and this hand-built website. Rain, Moonflower, and Broski are among those owned products. They show our product work; they are not client migration case studies.