Website and CMS Migrations

After we review your setup, the work can include checking which platform fits, a list of everything in the old and new systems, mapping content types and fields, IDs and links between items, formatted content and files, users, roles, access and publishing routines, a migration built in versions, keeping web addresses and connected tools working, checking old and new match, copying late changes, the switch-over, testing by your editors (UAT) and retiring the old system.

We compare editor tasks, how content is organized, translation and regional needs, publishing routines, user roles, security, connected tools, preview, the sites and apps that use the content, scale, platform limits, running costs and migration effort. We also compare fixing the system you have now. A popular platform is not automatically the right choice for you.

Each content type and field gets an old and new data type, a rule on whether it holds one value or many, whether it's required, checks, a default value, a fixed list of choices, a conversion rule, an owner and a planned use in the new system. Broken old values and fields that only the new system requires get clear conversion or problem-handling rules.

We set permanent IDs from the old system and either keep them or maintain a lasting map from old IDs to new ones. Linked records, parent pages, authors, tags and embedded items are loaded in a safe order and checked. Items that link to each other in a loop, or links the new system doesn't support, get a documented alternative.

Usually, but not by blind copying. We read the structure of the old content, convert the formatting and meaning the new system supports, map embedded items and set aside any code that is unsupported or unsafe. Some systems clean up HTML (web page code) automatically or can't show certain old building blocks, so some items may need new building blocks or a manual review.

We create a full list of files, transfer the files you own, check them with checksums (digital fingerprints that prove a file copied exactly), map image descriptions (alt text), captions, usage rights and other required details, and test every place they appear and the sizes the new system creates. A link to a file still stored on the old platform, sitting in a spreadsheet, is not treated as a backup of that file.

It depends on both platforms and how content is exported. We map active statuses and publishing routines and keep whatever the new system supports. Some exports leave out version history, schedules, tasks, memberships or original authors. Anything that changes or is lost is written down and approved by you before the switch-over.

Yes, when it's mapped separately. We set the default language, backup languages, how translations are linked, regional versions, publishing status, web addresses and hreflang tags (which tell Google which language or country version to show) where you use them, then check each language. Platform rules for languages and exports can stop a simple one-to-one transfer.

We match each person's tasks to roles in the new system, giving only the access each person needs, recreate users or single sign-on (SSO) groups through approved routes, and test creating, editing, approving, publishing and admin tasks. Passwords, memberships and audit history often can't be copied across directly.

We compare the old and new systems: counts, permanent IDs, required fields, fixed choice lists, links between items, files, checksums, statuses, languages, web addresses and sample pages. Every unexplained difference stays on a list of problem items, with an owner and a sign-off status.

We choose spreadsheet (CSV), database, API or a mix for each content type, and set page-by-page fetching, batches, order, parallel jobs, retries and waiting times between attempts. Runs use save points and permanent IDs, so they can restart or be repeated safely where the platform allows it. A full-size test run tells us how long the switch-over window needs to be.

A delta migration copies the approved changes made in the old system after the main copy was taken. We decide how changes are spotted, which version wins in a clash, how deletions are handled and when the final edit freeze starts, then run and check the delta and sign off the final cut-off. Timestamps or "last copied" markers need extra checks for deletions and anything unusual.

We list your valuable web addresses, map each one to the right new page, set up suitable direct permanent redirects (301s), and update internal links, canonical tags, hreflang tags where used, schema, robots rules (instructions for search engine bots) and sitemaps, then watch Google Search Console. We can't guarantee that rankings won't go up and down for a while after a big move.

Before launch, we agree the state we'd return to, how we'd get back there and the point at which we'd switch back, and we test it where the platform allows. Environment shortcuts or snapshots (saved copies of the whole system) can make recovery faster, but switching back may not undo content already sent to caches, search indexes, webhooks or outside systems.

Not automatically. CMS migration covers how content is structured, your records, publishing routines and the agreements with the tools that deliver content. A new theme, front end, website redesign or wider application move is scoped separately, or clearly combined in your proposal.

Only after the records, files, web addresses, page display, connected tools and editor work in the new system are accepted, the required archives and proof of record-keeping exist, nothing still loads files or data from the old system, and there are approved steps for closing access, connections and contracts.

Checking which platform fits and mapping your content can begin in days 1 to 3. The switch-over date is only set after a realistic test run, and depends on access, the number of records and fields, links between items, formatted text, files, languages, publishing routines, users, platform API limits, connected tools, late changes, the number of problem items and how fast approvals come.

Your price follows the data and delivery work found in our review: platforms, records, content types, fields, links between items, files, languages, publishing routines, APIs, setting up the new system, connected tools, matching checks, the switch-over, specialist work and retiring the old system. Your proposal states what we deliver, our assumptions, what is not included, timing and the fee.