CRM Migration Strategy: A Practical Plan for Swiss Teams

A good CRM migration strategy answers five questions before anyone touches an export file. What are we moving, what are we leaving behind, who is responsible for the data, how do we go live, and who can stop the cutover if it goes wrong? Tools matter far less than those decisions. Teams that answer them early usually get a boring migration, which is exactly what you want from one.

This guide is for founders and owners of small and mid-size Swiss companies who are replacing a CRM, consolidating several, or moving off a spreadsheet-and-inbox setup. It combines Swiss public-sector guidance (which is more rigorous than most vendor blog posts) with what we see in real projects at Ampersand. It ends with a checklist and a short FAQ.

TL;DR

• Treat the migration as a business and data project, not an export/import job. Write a short migration concept first: source data, volumes, quality, integrations, schedule, archiving, security, privacy and the retirement of the old system.
• Decide what to keep, clean or archive before you map a single field. Most of the pain comes from moving dirty data.
• Run a pilot migration with deliberately messy records, and validate it before the full move.
• Fix your go-live approach (one cutover or waves) and your rollback rules in advance, including who may call a stop.
• In Switzerland, you remain responsible for customer data even when a cloud CRM vendor processes it. Put the processing terms and exit path into the checklist.

Start with a migration concept, not a tool

Switzerland’s federal project-management method HERMES is blunt about what a system migration needs. Its guidance on drafting a migration concept lists the topics to analyze: the source data, quantities, frequency, quality, integration, feasibility, cost-effectiveness, schedule, archiving, data security, privacy and the planned decommissioning of the old system. Few commercial CRM guides cover that much.

You do not need a 60-page document. For a company of 5 to 80 people, two or three pages are enough, as long as each of those topics gets an honest answer. A useful template:

1. Goal. Why are we moving? Lower cost, a better pipeline view, an ERP or shop integration, a vendor we no longer trust? Write one sentence. It will settle many later arguments about scope.
2. Source systems. The old CRM, but also the spreadsheets, shared mailboxes, newsletter tool and invoicing system where customer data really lives.
3. Volumes and quality. Number of contacts, companies, deals, activities, attachments. Estimated share of duplicates and records without an owner.
4. Integrations. What reads from or writes to the CRM today: website forms, shop, ERP, accounting, telephony, support desk.
5. Schedule and people. Who owns the data on the business side, who does the technical work, and which weeks are off-limits (year-end closing, a big trade fair, a product launch).
6. Retirement. What happens to the old system, and when.

That last point is the one people skip. HERMES treats the decommissioning of the legacy system as part of the migration, not an afterthought. In practice, when nobody decides whether the old CRM becomes read-only, gets archived or is switched off, sales reps keep updating both, and you end up with two competing sources of truth.

Why the business side has to own it

A digitalswitzerland summary of an FHNW-led study from 2021 found that only half of the surveyed Swiss SMEs had a digital strategy, and 44% were dissatisfied with their digitalization progress. The study is a few years old, so do not read it as a 2026 market statistic. The lesson still holds: technology projects that are delegated as isolated IT replacements tend to disappoint.

For a CRM this means one named person from sales or customer service owns the outcome: field definitions, pipeline stages, what counts as an active customer. The technical team owns how the data gets there. If those roles blur, you will hear “the data is all there” from IT and “I can’t find my deals” from sales on the same day.

Decide what to keep, clean or archive

Data cleanup is the cheapest risk reduction in the whole project. Before mapping fields, sort your records into three buckets.

Bucket	What goes in	Typical examples
Keep	Active, accurate, useful records	Current customers, open deals, contacts with activity in the last 18 to 24 months
Clean	Valuable but flawed records	Duplicate companies, contacts with missing company links, inconsistent country or language fields, free-text job titles
Archive	Records you must retain or might need but will not work in daily	Closed-lost deals from years ago, old attachments, former employees’ activity logs

The 18 to 24 month threshold is a starting point we suggest, not a rule. Adjust it to your sales cycle: a company selling machinery with a three-year cycle needs a longer window than a web shop.

A cleanup pass that works in practice

• Deduplicate on stable keys first. Email address for people, a normalized company name plus postcode (or UID number, if you hold it) for companies. Merge before the migration, in the old system, so the history stays attached to one record.
• Standardize the fields that drive logic. Country, canton, language (DE, FR, IT, EN), lifecycle stage, lead source. Swiss data often mixes “Zürich”, “Zurich” and “ZH” in the same column, which breaks every later report and segment.
• Decide ownership. Every company and open deal gets an owner. Records without one are where deals disappear.
• Separate marketing consent from contact data. Keep the consent status, source and date with each contact. If you cannot show where a newsletter subscription came from, flag it rather than silently carrying it over.
• Freeze the schema. Agree that nobody adds custom fields to the old CRM during the project. A moving target costs more than any other single habit.

Track the numbers as you go: records before cleanup, duplicates merged, records archived, records to migrate. These become your reconciliation baseline later.

Settle privacy and the operating model before you move data

If you are moving into a cloud CRM, you are outsourcing data processing. The Swiss Federal Data Protection and Information Commissioner (EDÖB) lists an online CRM system among its examples of cloud computing. Its guidance on outsourcing says that even when you hand processing to a processor, you stay responsible for data protection. In plain terms: the vendor’s reputation does not transfer your obligations to the vendor.

That turns into concrete checklist items for the migration:

• A data processing agreement with the CRM vendor.
• The list of subprocessors, and where data is stored and accessed from.
• The transfer mechanism, if any data or support access leaves Switzerland.
• Access controls: who can see what, single sign-on, multi-factor authentication.
• Deletion and return terms, so you can leave later.
• Incident notification duties and audit rights.

“Hosted in Switzerland” is not a complete answer. Processing roles, support access from abroad, subcontractors and foreign legal exposure all matter, and the right assessment depends on your data, purposes and the parties involved. The EDÖB material is guidance, not individual legal advice, so if your CRM holds sensitive categories of data (health information, for instance), ask a Swiss data protection lawyer before you sign.

The EDÖB’s guide to technical and organizational measures is a good source for the engineering side: encryption, authentication, access governance and safeguards on data transfers should be designed into the migration itself. In practice that means no customer exports sitting in someone’s downloads folder, no data pushed through personal cloud drives, and temporary migration environments that are deleted when the work is done.

It also pays to ask a minimization question: do we need to migrate this field, this attachment, this ten-year-old contact at all? Leaving data behind is the easiest privacy control there is.

Choose one cutover or waves

HERMES ties migration strategy to rollout strategy. If you go live in one step, you migrate in one step. If sales goes first and customer service follows, or regions join in waves, then data migration, reconciliation, training and support must also happen in waves.

The two options compare like this:

	Single cutover	Phased waves
Best for	Small teams, one pipeline, few integrations	Several teams, regions or product lines
Main advantage	One clean switch, no parallel running	Lower risk, learning carries from wave to wave
Main risk	A problem hits everyone at once	Temporary dual systems and sync complexity
Typical safeguard	A weekend cutover window with a rehearsal	Clear rules about which system is authoritative for which records

For most teams under about 30 users with a single sales process, a single cutover after a rehearsal is simpler and cheaper. Once you have multiple teams with different pipelines or integrations feeding the CRM, waves are worth the extra coordination. Whichever you choose, say it in writing, because it determines training dates, freeze periods and support cover.

Run a pilot migration that tries to break things

The Swiss Federal Chancellery’s cloud-exit guideline was written for federal agencies moving specialist applications, but its controlled-migration logic transfers well to a CRM. It calls for an approved final plan, functional tests in the target environment, a pilot migration of part of the data with validation, logging of every migration step, and final data, performance and security validation before production use.

The pilot is a control point, not a formality. Choose the sample to be nasty, not representative:

• Duplicates you thought you had merged.
• Inactive and unsubscribed contacts.
• Opportunities at every pipeline stage, including lost and on-hold deals.
• Records with attachments, long notes and special characters (umlauts, accents, apostrophes in names).
• Contacts with consent records.
• Records touched by an integration, such as an order synced from a shop or an invoice number from your accounting tool.

Then validate in two ways. Quantitatively: do record counts per object match your baseline, and do totals such as open pipeline value agree? Qualitatively: have two or three people from sales open their own accounts and tell you whether the story of each customer reads correctly. Counts can match perfectly while the timeline of activities is scrambled, and only a user notices that.

Fix the mapping, wipe the target, and run the pilot again. Doing this twice is normal.

Define cutover and rollback rules in advance

The same federal guidance frames migration as a traceable operation with explicit recovery and continuity requirements. Translate that into five decisions, made before the cutover weekend and not during it:

1. Acceptable downtime. How long can sales work without the CRM? An hour, a day, a weekend?
2. Recovery point. How much recent data can you afford to re-enter if you must roll back? Zero, or one day’s worth?
3. Rollback conditions. Name measurable triggers: for example, record counts off by more than your tolerance, a broken lead-form integration, or the pipeline total not reconciling.
4. Decision authority. One named person who can call a stop, and a deputy.
5. Log of steps. Every migration step is recorded: who ran what, when, with what result.

Write down the old system’s state as well. Take a full backup, keep it read-only, and do not delete anything until the new system has run through at least one complete reporting cycle, such as a month-end.

Rewire the integrations

A CRM rarely lives alone. Website forms, the shop, the ERP, the accounting tool, email and telephony all read or write to it. List each connection, its direction, and what breaks if it fails. Re-create and test them in the target environment before cutover, not after. Webhooks and API keys that still point at the old system are a classic source of lost leads in the first week.

If your integrations are mostly point-to-point scripts built by people who have left, the migration is a good moment to replace them with a documented, monitored setup. That is also what makes later automation realistic: the digitalswitzerland AI playbook for Swiss SMEs notes that CRM automation becomes viable once ERP and CRM data and APIs are in place, and it recommends moving from bought SaaS tools to integration, and only then to custom development when your processes, data, security or control needs justify it.

After go-live: finish the job

Go-live is not the end. The federal guidance expects security documentation and the exit strategy to be updated after migration. For a CRM team, the first 30 days should include:

• Hypercare. A named person answers questions the same day, and you collect issues in one list.
• Reconciliation. Re-run your baseline counts and pipeline totals a week and a month after go-live.
• Old system retirement. Switch the legacy CRM to read-only on a set date, archive what you must retain, and cancel the contract on the date your retention decision allows.
• Documentation. Field definitions, integration map, user roles, and how to export your data if you ever need to leave.
• Adoption check. Look at who actually logs activity. If two reps are still tracking deals in a spreadsheet, find out why.

Once the data is trustworthy, automation is worth considering. The same playbook names lead routing, meeting summaries, customer-feedback clustering, cross-sell suggestions and support triage as candidates, and it advises monitoring each for quality, security and data leakage. Start with one workflow, measure it, and expand only if it earns its place.

A CRM migration checklist

Before

• [ ] One-sentence goal and a named business owner
• [ ] Migration concept: sources, volumes, quality, integrations, schedule, archiving, security, privacy, retirement
• [ ] Keep, clean, archive decisions made and recorded
• [ ] Duplicates merged, key fields standardized, every record owned
• [ ] Data processing agreement, subprocessors, locations and exit terms reviewed
• [ ] Field mapping signed off by sales or service
• [ ] Single cutover or waves chosen and written down

During

• [ ] Pilot migration with duplicates, inactive contacts, all deal stages, attachments and consent records
• [ ] Counts and totals reconciled against the baseline
• [ ] Users reviewed their own accounts
• [ ] Integrations rebuilt and tested in the target
• [ ] Downtime, recovery point, rollback triggers and decision authority agreed
• [ ] Full read-only backup of the old system
• [ ] Every migration step logged

After

• [ ] Hypercare owner named for the first weeks
• [ ] Reconciliation repeated after one week and one month
• [ ] Legacy system read-only, then archived or closed on a set date
• [ ] Documentation, roles and export path updated
• [ ] First automation candidate chosen, with a quality check

Common mistakes

Migrating everything “just in case.” Every extra record is extra mapping, extra testing and extra privacy exposure. If you would never search for it, archive it.

Mapping fields in a spreadsheet nobody validates. Mapping is a business decision. A field called “Status” can mean three things in three teams.

Treating training as a launch-week task. People need to see their own data in the new system before go-live, ideally from the pilot.

Letting the vendor’s importer define your process. Import wizards are fine for clean, simple data. They are a poor substitute for a plan when you have custom objects, multiple sources or integrations.

No exit thinking. Whatever you move to, know how you would leave. Export formats, deletion terms and a documented data model keep today’s migration from becoming tomorrow’s lock-in.

Where we can help

At Ampersand, a small Zurich studio, senior engineers stay on a project from the first conversation to handover, which matters in migrations because the people who understood your messy data in week one are the ones who sign off the cutover. We offer system migration, replatforming and integrations for shops, CRM and ERP, plus audits if you want an independent look at a plan before you commit. After go-live, our Run & monitor plan costs 750 CHF per month, and our Guidance advisory plan costs 799 CHF per month. You can see the full range on our pricing page and examples of previous work on our works page.

FAQ

How long does a CRM migration take?

It depends mostly on data quality and the number of integrations, not on record count. A small team with clean data and one pipeline can move in a few weeks. A company with several sources, custom objects and a shop or ERP connection should plan for a few months once cleanup, pilot runs and training are included. Ask for a schedule built from your own migration concept rather than a generic estimate.

Should I clean data before or after migrating?

Before, in the old system, and then validate it again after the pilot. Merging duplicates in the source keeps each customer’s history on one record, and you get a reliable baseline for reconciliation. Cleaning afterwards means paying to map and test records you did not need.

Do Swiss data protection rules apply to a CRM migration?

Yes, if the CRM holds personal data, which it almost always does. According to the EDÖB, you stay responsible for lawful processing even when a cloud provider processes data on your behalf, so review the processing agreement, subprocessors, storage and access locations, and deletion terms. For sensitive data or cross-border setups, consult a Swiss data protection lawyer.

One cutover or a phased rollout?

A single cutover suits small teams with one sales process and few integrations. Phased waves suit several teams, regions or pipelines, because you can learn from the first wave. Whichever you pick, the data migration, training and support plan must follow the same pattern.

What should I do with the old CRM afterwards?

Decide before the migration. Keep it read-only through at least one full reporting cycle, archive what you are required or want to retain, then close it on a set date. Leaving it open and editable is how two sources of truth appear.

Sources

• HERMES: Migrationskonzept erarbeiten
• Swiss Federal Chancellery: Cloud-Exit-Strategie, Guideline
• EDÖB: Cloud-Computing
• EDÖB: Outsourcing (Auftragsdatenbearbeitung)
• EDÖB: Leitfaden zu den technischen und organisatorischen Massnahmen des Datenschutzes
• digitalswitzerland: KMU-Strategien im digitalen Zeitalter
• digitalswitzerland: AI playbook for Swiss SMEs