When a CRM project is described as a data migration, there is a big risk that the organisation repeats the same mistakes in a new system. This case study on HubSpot migration shows what happens when the move is instead treated as a commercial change project: processes are cleaned up, responsibility is sharpened and data is given a clear job to do.

The case is based on a representative B2B scenario from a complex sales organisation with international growth ambitions. Customer details and internal specifics are anonymised, but the problems, priorities and way of working are drawn from the kind of CRM work that decides whether a migration becomes a lever or yet another costly system switch.

The starting point: the data existed, but control was missing

The company had grown faster than its commercial infrastructure. Marketing worked in one system for campaigns and forms, the sales department had another CRM and the customer team kept important information in spreadsheets. There was no reliable picture of which accounts were being worked, which leads actually reached sales or where in the pipeline deals got stuck.

The problem was not primarily a lack of data. The problem was that the same company appeared in several places, with different owners and different statuses. A lead could be qualified according to marketing but completely invisible in the sales system. A deal could be reported as won without anyone knowing which original initiative had created it. When leadership asked about conversion, sales cycles or channel quality, the answer was often a mix of manual extracts and educated guesses.

The ambition with HubSpot was therefore bigger than replacing tools. The company wanted to build a shared revenue engine where marketing, sales and the customer team worked on the same base data and where reporting could be used for decisions, not for rework ahead of the management meeting.

The usual misprioritisation

The first temptation in such a situation is to move everything. All contacts, old activities, historical deals and fields that someone once created. That gives a quick sense of security, but rarely creates a usable CRM.

In this case the starting point was the opposite: only data that supported a future process would be moved. History needed for analysis could be archived, but it should not burden the salesperson's everyday work. A CRM is not a museum. It is an operational system for creating and driving revenue.

The goal of the HubSpot migration

The project was defined from four business questions, not from features in the platform. Which target groups and accounts should be prioritised? When is a lead ready for sales contact? How should the sales process reflect real decision steps? And which metrics must leadership be able to trust every week?

It sounds basic, but many migrations start before these questions are answered. The result is a CRM with standard fields, generic pipeline stages and automations that nobody really owns. The technology works, but it does not change the way of working.

Here a few principles were set early. A contact should have a clear relationship to the right company. An account should have a named owner when active work was under way. A deal stage should correspond to real commercial progress, not a salesperson's gut feeling. And every mandatory field needed to be justified by a decision, an automation or a report.

How the migration was carried out without stopping sales

The work was divided into clear phases, but the project was run close to the business. That is crucial. A CRM owner can configure objects and fields, but cannot alone decide what is required to qualify a deal or handle several decision-makers in an enterprise case.

First: mapping data and processes

The team began by taking inventory of existing data sources. Contacts, companies, deals, activities, form responses, consents and owner information were reviewed. Duplicates were identified, fields were compared and data was classified as necessary, valuable or redundant.

At the same time, the actual sales process was mapped through conversations with salespeople, marketing and account managers. It was an important contrast with the process that had been documented. In practice there were different definitions of a qualified lead, different sales stages for different markets and different ways of recording the next activity. It was these variations that needed to be dealt with first.

The goal was not to force every deal through the same template. A shorter transactional deal and a longer deal involving procurement, legal and several decision-makers need different structure. The core logic, however, needed to be shared: the same definitions, the same responsibility and the same criteria for when a deal moves on.

Then: a data model that supports the business

In HubSpot, a structure was built around companies, contacts, deals and clear lifecycle stages. The company's segmentation was simplified so that it could be used in both reporting and daily work. Instead of a large number of fields for industry, market, potential and status, a limited set was created that could actually be kept up to date.

For deals, stages were defined based on verifiable events. A stage required, for example, a confirmed problem, an identified decision process or a planned next meeting. That made pipeline data more reliable and gave the salespeople a clearer way to prioritise.

Lead scoring was not introduced as a black box. First a simple model was built where the right company profile and the right behavioural signals weighed more heavily than volume. A lead from a prioritised account with clear interest in a relevant solution was handled differently from an anonymous form download. The model could then be adjusted once the team had enough outcomes to analyse.

After that: migration, quality assurance and testing

Data was moved in controlled batches, not in one big sweep. Each import was validated against rules for format, ownership, duplicates and the link between contact and company. A sample of records was checked manually by users who knew the customer picture, because automatic checks do not capture business relevance.

In parallel, the central flows were tested: form to contact, qualification to sales, deal creation, handover to the customer team and reporting to leadership. When a flow broke, the process or configuration was adjusted before the next batch of data was moved.

It took more time than a pure technical import. But the alternative would have been to discover incorrect owners, broken automations and misleading reports after launch, when trust in the new system had already had time to fall.

What changed after launch

The clearest improvement was not a single dashboard. It was that commercial conversations became more concrete. Marketing could see which activities created meetings with the right accounts, not just form responses. Sales could prioritise based on account potential, buying signals and defined next steps. Leadership could follow pipeline quality without having to request manual compilations every week.

Workflows also removed friction in handoffs. When a lead reached agreed criteria, the right task was created, the right owner received a notification and follow-up could be measured. That did not automatically give better sales results, but it made the shortcomings visible. If qualified leads were not followed up within the agreed time, it could be seen. If a certain market produced a lot of activity but few deals, it was possible to investigate the cause.

That is a significant difference. A CRM should not hide a weak process behind nice reports. It should make the bottlenecks clear enough to fix.

Three decisions that made a difference

First, not all history was migrated. By setting rules for what was relevant, the team kept a CRM that could be worked in from day one. Second, the pipeline was built around the customer's decision process, not around internal requests for more statuses. Third, every automation was given an owner and a business purpose. Automation without ownership quickly becomes invisible and hard to maintain.

There is also an important trade-off around level of detail. Too little structure gives poor data. Too much structure makes the sales team work around the system. The right level depends on the complexity of the business, the number of markets and how mature the way of working already is. A B2B company should therefore start with what is required for steering and execution, then refine once usage is established.

HubSpot migration is the start of ongoing management

Launch day is not the end point. When the CRM is used for real, new questions arise: Which fields are left empty? Where do deals get stuck? Which signals predict a good meeting? Which segments should get different treatment? That is where the value of a shared data model begins to grow.

The most useful next action is often simple: pick a few metrics that link activity to revenue, review them regularly and adjust the processes when the data shows a real problem. A better CRM is not created by more objects or more automations. It is created when the team can consistently make better commercial decisions than the week before.