Our CMS data is pretty messy. Do we need to clean it up before you migrate it?
No. We first copy your data into a temporary staging database, and cleanup happens there before anything reaches the new platform. You set the rules, such as dropping records older than a cutoff date or leaving out records you no longer need, and we apply them in the migration scripts.
Can we change which fields we bring over, or how they map, after the project has started or even after the migration is finished?
Yes. Tell your migration team which fields you want to add or remove, or how you want them mapped, and they will update the mapping in the migration script before the full migration runs, so the full migration uses your latest field selection. If records have already been migrated, including after the migration is finished, we re-run the script with the revised mapping, which overwrites the earlier values on those records. For example, if you change your dropdown options, once you've updated them in the new platform we add a sheet to your migration checklist that pairs each original value with the new options, and when you've completed it we update every previously migrated record to match. On a large account this re-sync takes time, because every migrated record has to be updated, so we give you an estimate before it starts.
Can we migrate only part of our CMS data, such as recent records, one team's records or specific record types?
Yes. The migration scripts are built for your project, so you define exactly what moves when we scope the migration: for example one team or category, a date range such as the last two years, specific record types, a list of records you share with us, or records with a status or other value you choose to include or exclude. We pull only that data, and before the full run we confirm the record count and date range with you, so the scope is exactly what you intended and data you no longer need is not brought into the new platform.
Can you migrate data from a separate database alongside our current CMS platform?
Yes. Each migration is built as a custom script, so another source, such as a SQL database, can be part of the same project. We ask for read access and agree with you which tables or queries hold each value, then confirm the mapping with a sample migration before the full run.
How much of our team's time will our CMS migration take, and how do we decide how our fields map to the new platform?
Very little, and nothing technical. Your ClonePartner engineer sends you a migration checklist as a shared Google spreadsheet that lists every field in your current platform with a recommended mapping to the new one, and standard fields are mapped automatically. Your team, who know how the data is actually used, confirm where each custom field should land and add notes and preferences straight into the sheet, and we work through any open questions with you. You approve the checklist, then review a sample migration to confirm everything lands where you expect. We handle the scripting and migration runs ourselves, building the migration scripts from the agreed mapping so every field lands where you decided it should.
Will links between our records still work after the migration?
Yes. We move your data in two passes. The first pass creates every record in the new platform and stores its new ID. The second pass goes back and points each reference at the new record, so links between records lead to the right place.
Will loading data into the new platform slow down our team or disrupt our other integrations?
It can have some effect while the migration is running, and we schedule around your team if it does. The load usually comes through the new platform's API rather than its interface, but other integrations on the same account can share that API's rate limit. If your team notices a slowdown, we can pause the run and resume it later, or schedule it outside your working hours, for example over the weekend.
Are attachments migrated, and how do you make sure none are missed?
Yes. Attachments are downloaded from your current platform and uploaded to the new one as real files on the same records, wherever it accepts files on that type of record and within its file size limit, not left as links back to the old system. To make sure none are missed, your Migration Validation Report checks attachment integrity by checksum alongside the record-count comparison, and we can also run an attachment count check against your source and share the results. You can review attachments in the sample migration before the full run.
Will API rate limits on our old or new platform slow the migration down or cause data to be missed?
They affect how long the migration takes, not what it includes. We plan the schedule around both platforms' limits, run extraction and loading in parallel where we can, and keep the job running until everything is pulled; requests that hit a limit are retried rather than skipped, and the record-count comparison in your Migration Validation Report confirms everything arrived. Where a platform lets you raise its limit for the migration, for example as an add-on, doing so shortens the run.
Can you move our account to another data center region on the same platform, such as from the US to the EU?
Yes, where the platform offers hosting in the region you need. We treat it like any other migration: both accounts are connected, your data is copied from the account in its current region to a new account in the target region, and a delta migration at an agreed time brings across anything that changed. Your team keeps using the current account until switchover, and you can use the move to leave older history behind, for example by migrating only open and recent records.
Do you also move or reconnect our integrations, such as a data warehouse connection, in the new platform?
Not as part of the migration itself. Your team reconnects each tool, such as a data warehouse connection, to the new platform after cutover. If you want an integration or data pipeline rebuilt for the new platform, we can scope and quote it as separate work.
Our current system is hosted on-premises behind a firewall. Can you still migrate it?
Yes. Your system doesn't need to be cloud-hosted: all migration traffic comes from one fixed IP that your IT team can whitelist in the firewall, instead of opening broader access. We then read from the system's API or connect to its database directly, and on-premises sources start with a short discovery step to learn how your installation stores its data.
Will dropdown values come across as readable labels or as the codes stored in our old system?
As readable labels, unless you choose otherwise. Where your old system stores a code behind each option, we map the codes to the labels your team actually sees, so dropdowns in the new platform show readable values. We confirm this with you during mapping, and we flag any code that doesn't identify a single value on its own so you can pick a better source field.
Can you migrate our data into the new platform while we're still on its free trial?
Yes, as long as the trial account gives us the access we need and stays active until the final delta. Tell us the trial end date when you complete the migration checklist, and we plan the schedule to finish the full migration before it ends. The sample migration also lets you see your own data in the new platform while you are still evaluating it.
Can you rename, combine or change the type of our fields during the migration, instead of copying them one-to-one?
Yes. The migration checklist is the source of truth for the migration, so you can rename fields, change their type or merge several into one rather than copying them one-to-one. Where the types differ, the scripts convert the values, for example text in your current platform to a number in the new one, and you check the result in the sample migration.
What if our current platform's API is outdated, poorly documented or doesn't return all of our data?
We can usually still migrate it. Each migration is written as custom scripts, so we work with whatever access your current platform offers: its API, even an older or less common one, an export or database backup, and where the API leaves something out, another route where possible, such as the platform's interface with access you grant or another source the data came from. If the vendor has to switch on API access for your account, we tell you exactly what to request, and we confirm what is reachable during scoping and on the sample migration. Once the data is pulled, we share the record counts and the oldest record we have so you can confirm nothing is missing. Some items can't be reached by any route, and in that case we tell you which ones; after the migration you also get a list of anything that didn't come across, with the reason.
Will our tags and labels carry over to the new system?
Yes, where the new platform supports them. Tags and labels are part of the field mapping and are applied to the same records in the new platform. Where an old tag has no match there and can't be created, we map it to an existing tag you choose, and you can check how your tags come across in the sample migration before the full run.
Can the access permissions and restrictions from our old system be carried over to the new one?
Yes, where the new platform's permission model supports them, by rebuilding them there rather than copying them. We map each restricted area of your data, such as a department, to the closest control the new platform offers, agree with you which of your current teams or groups get access, and apply it to the records as they are migrated. We test the restrictions on a non-sensitive set of records before the full run, and we flag content that is hidden in your current platform in a way that won't carry over, so it isn't exposed by accident.
Can you migrate our CMS workflows and automations, or only our data?
Both can be in scope. Your records are the core of the migration, and workflows, rules and automations can be added: we recreate them in the new platform using its own conditions and actions, since automations don't copy across platforms as they are. Where the new platform's API can't create them, they are set up through its interface instead, and we agree during scoping exactly which ones we rebuild and which your team or implementation partner will handle.
Do we need to buy API access or an add-on licence on our current platform before the migration can start?
It depends on your current platform. Some only open their API through a paid add-on, such as a developer or web services licence, or only on certain plans. We check this for your platform during scoping and tell you before kickoff if anything needs to be bought or enabled, so it doesn't hold up the start.
Can you migrate attachments we store outside the platform, such as in our own Amazon S3 bucket?
Yes. You give us read access to the bucket, for example with temporary credentials, and we pull the files from it and attach each one to the matching record in the new platform. Part of the work is establishing how the bucket's folder or file names link back to your records, and the sample migration lets you confirm the files land on the right records before the full run.
Will the data we migrate count toward the new platform's plan limits or storage charges?
It depends on the new platform's plan. Migrated records arrive as regular records in the new platform, so whether they count toward its record or storage limits is set by that platform's pricing, and its own team or your implementation partner can confirm how your plan treats them. If limits are a concern, you can reduce what moves, for example by migrating only the last one or two years of history.
Is your know-how for handling tricky differences between platforms documented, or does it depend on particular engineers?
It's documented. Each project's mapping, including how differences between the two platforms are handled, is written into the migration checklist, which is the source of truth for the migration, and the migration scripts implement that mapping in code. That way, how every field is transformed can be looked up in the project's own documents rather than depending on one person's memory.
Can you run the migration into a sandbox or test environment before production?
Yes. If you have a sandbox or test environment, we can run the migration there first, so your team can test and approve it before we run it in production. Where you keep more than one test environment, such as UAT and a training environment, the migration can be run into each of them before production.
What data can be migrated between CMS platforms?
We migrate your core records, including custom fields, taxonomies, media, revision history, and full content relationships, wherever the new platform can store it. Because we write custom scripts for your exact data model, we also handle edge cases like inline images, multi-language content, URL redirects, and cross-object relationships that automated tools typically skip.
Superhuman Docs (Coda)
Claude, 
ChatGPT or 
Cursor. Describe the move in plain English; the agent runs it.
Notion
Slab
ConfluenceSoon
Google DocsSoon
