The 10 Steps of a CRM Implementation That Actually Sticks

Updated 9 November 2026 with where to get implementation support, what your side has to do to make it work, what a bad implementation costs, and what should be true 90 days after go-live. Updated 26 October 2026 with how long each kind of implementation takes and what it costs, how to connect the new CRM to the systems you already run, what you should hold at the end, and a one-page view of the ten steps.

A CRM implementation runs in ten steps, in this order: write down what the new system has to do, choose the platform, clean the data and name the team, define a successful transfer in numbers, get the final yes from the people who will use it, budget for the dip, leave room for next year, roll out the basics, assess against your criteria, then revise and go full.

The hard CRM implementations are the second ones.

A first implementation starts with an empty account and a team who have never had one. A replatform starts with a decade of records, four integrations nobody documented, three pipelines that made sense in 2019, and a sales team with muscle memory. Add a department that has never touched the CRM and you are running two projects at once: a migration and an adoption.

The ten steps below are the order to work in. They are the same ten steps whether you are moving off a system your team has outgrown or extending the one you already run, but each step means something different the second time around, so that is how they are written here.

Two of them get skipped almost every time, and both cost real money later: who owns the code your partner writes for you, and what Australian privacy law says about moving customer records between systems. Those are steps two and three.

The ten steps

In order:

1. Write down what the new system has to do that the old one could not.
2. Choose the platform, and read who owns what you commission.
3. Clean the data, name the team, and check who is allowed to see it.
4. Define what a successful transfer looks like, in numbers.
5. Get the final yes from the people who will use it.
6. Budget for the dip as well as the subscription.
7. Leave room for what you will want in a year.
8. Roll out the basics: test transfer, core rollout, full implementation.
9. Assess against the criteria you wrote in step four.
10. Revise, go full, and keep the team together.

The order we work in on a HubSpot implementation. A first CRM moves through the stages faster than a replatform, but skips none of them.

1. Write down what the new system has to do that the old one could not

On a first implementation this step is a brainstorm. On a replatform it is a list of complaints, and you already have it.

Write the specific ones. The report nobody can build. The field sales fill in by hand every week because the integration never wrote it. The handover between sales and service that happens in email because the old system had no way to hold it. Then get the numbers next to them: how long a deal sits in each stage now, how many records you actually have, how many of those are duplicates.

This is also the moment for mapping your sales process before onboarding starts. The process you run is the thing the new system has to hold, and the version in the leadership team's head is rarely the version the reps follow.

Keep the ambitious list, then split it in two: what has to work in the first week, and what you want by the middle of next year. Step eight needs that split.

2. Choose the platform, and read who owns what you commission

If you have spent two minutes in a room with us you know we froth HubSpot. It is not the only CRM going, so check the competition properly, and make sure you are not paying every month for features you are certain you will never open.

Then run a risk assessment, because you are moving live data out of a system your business currently depends on. The four risks worth writing down:

• Loss of data, some of which may be hard to recover.
• Loss of time, because a transition always creates a slow-down.
• Data corruption, the errors you do not find until months later.
• Loss of functionality, things that used to be easy and now are not.

The mitigation is a sample transfer. Any decent data partner will run a data quality audit on a test sample before anyone commits to the full run.

Now the part that gets skipped. A replatform almost always involves custom work: a custom coded workflow action, an integration between HubSpot and your ERP, a migration script, a calculated property nobody else has. In Australia the default position is that whoever wrote the code owns copyright in it, even though you paid for it, unless the contract assigns that copyright to you. IP Australia sets out the rule. So read the agreement before it is signed, and look for an assignment clause covering anything commissioned, or at minimum a licence broad enough that your next partner can maintain what this one built. The version of this that hurts arrives two years later, when you want to change partners and the integration holding your quoting together belongs to someone else.

If you are weighing doing it in house against bringing someone in, where to get CRM implementation support below compares the two.

3. Clean the data, name the team, and check who is allowed to see it

A migration is the one chance you get to leave the rubbish behind. Weed out the dead records, fix the fields you know are wrong, and decide what you want to be able to report on in future, which is usually more than the handful of fields you fill in today. Our CRM implementation and migration page sets out how we decide what to keep, fix or leave behind.

While you are in there: moving customer records means moving personal information between systems, often to a new storage location and usually through a third party's hands. That is exactly what the Privacy Act 1988 and the Australian Privacy Principles under it govern, and the OAIC publishes both. Two practical consequences. Keeping that information secure is your problem under APP 11, including while it sits as a CSV export in someone's downloads folder. And there are separate rules about disclosing personal information overseas, which is worth checking before a partner's offshore team is handed a copy of your contact database. Do the deletion before the migration. Records you never move cannot leak.

This session from our YouTube channel, recorded at a HubSpot User Group, covers HubSpot data migration and bringing your data home to Australia, including choosing the Australian data centre.

In parallel, name the team. Some of it will be in house, some of it your partner's. The skills you need:

• Project manager, to own the plan and the sequence.
• Data analyst lead, to own the migration itself.
• Systems engineer, to handle the technical work and the connections.
• Application developer, to build the parts the platform does not do as standard.

On a replatform there is a fifth person who never appears on the project plan and should: whoever knows why the old system is the way it is. Half the odd configurations in there are load bearing, and only that person knows which half.

Leadership is what makes a rollout work, especially leaders who can explain what the change is for. Beyond them you need the yes from management, sales and marketing, customer service and R&D.

4. Define what a successful transfer looks like, in numbers

This part is not hard, it is just usually skipped. Decide what done looks like and write it down before the transfer, because afterwards everyone argues from memory.

On a replatform the criteria are countable. Record counts match on both sides. Every open deal has an owner and a close date. The three reports your CEO opens return the same numbers as the old system for the same date range. Every integration that wrote to the old CRM writes to the new one. Get agreement on that list, because changing the definition after the build has started is slow and expensive.

5. Get the final yes from the people who will use it

Here the project team puts the proposal to the whole company, and you will get a volley of feedback back, some of it contradictory. Take it anyway. Somebody always raises the unforeseen problem that saves you a fortnight.

Middle managers matter most at this point. They may not have contributed to the design, but they know how their customer-facing teams will actually use the thing on a Tuesday afternoon. Spend real time selling the change internally.

On a replatform you will hear one objection over and over: the old one did X. Half the time they are right. Keep a public list of those, and answer each one, including the ones where the answer is that we are not rebuilding it.

6. Budget for the dip as well as the subscription

Set a realistic number before the transfer starts. Subscription charges and partner fees are the easy part. The rest of it: downtime, time out of the field for training, and the period where productivity drops while people learn where everything moved to.

Replatforming adds one more line most budgets miss. You will run both systems at once for a while, because nobody turns the old one off the day the new one goes live. Put the overlap in the plan.

HubSpot's dashboards and menus are plain enough that most teams get productive quickly, which shortens the dip. It does not remove it. If you want the other side of the ledger, this is what a bad implementation actually costs.

7. Leave room for what you will want in a year

Build for the department you are adding next as well as the one you are migrating now. The test is simple: if bringing service into a sales-only portal means rebuilding your property structure and renaming your pipelines, you built it too narrow.

Allow budget for the parts you will not use immediately. The custom object you will want when the second brand arrives is much cheaper to design now than to retrofit later.

8. Roll out the basics

An implementation runs in three stages:

1. Test data transfer.
2. Core systems rollout.
3. Full implementation.

Move a sample of customer data first, check it against your step four criteria, then roll out the core and get people using it fast so business continuity does not suffer. Your partner should be running training, in person or as material people can work through themselves.

Order matters more on a replatform than on a first build. The core is whatever your team uses every day: the pipeline, the records, the two reports leadership reads. Marketing email, campaign tracking, the newsletter and the social connections can follow a fortnight later on their own timetable, and nobody will notice.

9. Assess against the criteria you wrote in step four

This is where you find out whether reality matches the plan. If it does not, you have not gone to full implementation yet, so you can still change it before everyone is deep in.

Four things to judge:

• Integration, how well has the transition gone?
• Completeness, is all the data there?
• Accuracy, is it right?
• Fitness for purpose, can the team do their job in it?

You will get plenty of feedback from the people who have to live in it. Some of that is a genuine gap and some of it is that nobody likes learning a new system. Separating the two is the job. Give it a few weeks and most of the unfamiliarity complaints stop arriving.

10. Revise, go full, and keep the team together

Make the changes, take them back to the team, then go.

Two things after that. Plan a review at set intervals, monthly at first, and do not disband the implementation team the week after go-live. You will still need them as you finesse the setup and train the next intake.

Then name the person who owns the portal. A replatform with no owner drifts back into the state the old system was in, one unapproved field at a time, and in three years someone will write step one all over again.

How long does a CRM implementation take, and what does it cost?

It depends most on whether there is an old system to move off. These are the ranges on our CRM implementation page, in AUD and before the HubSpot licence.

The import itself takes hours. Our CRM implementations start from about $7,000 plus the licence. On our reading of published Australian partner pricing, a partner-led setup runs from about $8,000 for a clean single-hub setup to $35,000 with a real migration and integrations. How CRM setup pricing works covers what moves a quote up or down.

How do you connect the new CRM to the systems you already run?

Most replatforms are really integration projects. The CRM is the easy part, and the accounting system, the ERP, the booking tool and the website forms that write to it are where the weeks go. Work through each connection in the same order:

• List every system that reads from or writes to the old CRM, including the ones nobody owns. Someone set up a nightly export to a spreadsheet three years ago, and finance still opens that spreadsheet.
• Name the system of record for each field. If both the CRM and Xero hold a billing address, decide which one wins when they disagree, and write it down.
• Set the direction of each sync. One way is simpler and safer. Two way sync is where duplicates and overwrites come from, so use it only where both sides really edit the record.
• Use a native connector before custom code. HubSpot's App Marketplace covers the common Australian tools. Custom integrations cost more to build and to maintain, and the contract should say who owns the code.
• Test with the sample transfer, and point test integrations at the vendor's test environment, never at a live system.
• Watch the sync errors after go-live. A connection can show as connected while nothing is passing through it. Check the logs weekly for the first month.

For the technical side, our HubSpot API and webhook integration guide goes deeper.

What should you have in hand when it is done?

Ask for these by name before you sign, and check them off at handover. If one is missing from the proposal, it is either out of scope or nobody thought of it.

• A pipeline built on how your team sells, with the entry rules for each stage written down.
• A property structure that marketing, sales and service can all read the same way.
• Migrated data that matches your step four numbers, with duplicates merged and consent carried across.
• The core workflows: lead routing, follow-up tasks and the handover from sales to service.
• Email and calendars connected for every user.
• Reports that answer the questions leadership actually asks, checked against the old system for the same dates.
• Forms and landing pages connected, so new contacts arrive with their source recorded.
• Training by role, with recordings for the next person who joins.
• Permissions set so people see what their job needs.
• Handover documentation your own team can follow without calling the partner.

Where do you get CRM implementation support, and what should it buy you?

You can run the implementation in house, bring in a freelancer or admin, or use a partner who has run the same kind of migration many times. Whichever you pick, it should buy you a data model mapped to how the business runs now, a migration with nothing lost or duplicated, integrations you own, training by role, documentation and someone who knows the setup when it has to change.

The in house route moves fast and deals with the problems when they show up: data carried across from the old system, workflows that break, a team not using it properly, reports nobody trusts. A partner maps the process to the architecture before anything moves, runs the data audit on a sample, validates the import in a test environment, and documents what was migrated. The differences that matter most are easy to miss when you are comparing quotes:

Ownership is the line Australian buyers assume is automatic. IP Australia sets out that IP a contractor creates belongs to the contractor unless the contract says otherwise, while employers own the IP their employees create in relation to the business. That is why an in house build and a contracted one sit differently. Workflows and properties built inside your own portal live in your account, so they stay when a partner leaves. Custom code, integrations and themes can sit outside it, and they are the question. One line in the agreement fixes it, and it is much harder to add later.

Our HubSpot implementation and onboarding page sets out the phases, timelines and AUD cost bands we work to, and HubSpot admin, freelancer or partner: what each costs compares the support models side by side.

What does your side have to do to make implementation support work?

Five things decide most of the outcome, and none of them sits with the partner.

• Put the right people in discovery. The person who signed the contract is not always the one who knows how the business runs. The rep who knows the real pipeline, the marketer who knows what a good lead looks like and the service person who handles complaints shape the architecture. Their absence becomes assumptions.
• Decide, and decide in writing. Every decision deferred during the build becomes rework. When you are asked whether deal amounts are required at stage two or stage three, or what your MQL definition is, give an answer.
• Turn up to training. Role based sessions run once. The person who misses theirs becomes the one who uses HubSpot differently and spoils the data for everyone else.
• Use it every day from go-live. The habits from the first 30 days are the habits the team will have in year three.
• Get the IP assignment into the contract before the build starts, while it is still an easy ask.

What does a bad CRM implementation cost?

The setup fee is usually the only cost anyone wrote down. The others arrive later and keep growing with the business:

• Decisions made on numbers that are wrong. When stages do not match reality, dead deals stay open and half the records are missing the fields the reports need, the dashboards still produce confident charts. Hiring, budget and resourcing decisions get made on them. A wrong number you trust does more damage than no number, because with no number you know to be careful.
• A team that gives up on it. Nobody announces it. The rep keeps the real notes in a spreadsheet, the marketer exports the data to work on it elsewhere, and the real pipeline conversation happens in a meeting instead of the system. Winning a team back to a system they have written off is much harder than getting them to adopt a good one the first time.
• Code you turn out not to own. This one stays hidden until you try to leave, often halfway through walking away from an implementation already judged beyond saving.
• The rebuild. Fixing a structure that years of records from several teams now sit on top of usually means rebuilding it, and paying for the implementation twice.

For the other number in that sum, here is what a HubSpot build costs a 100 person Australian business, and how CRM setup pricing works for a smaller team.

What should be true 90 days after go-live?

If the implementation support delivered what it should have, all of these hold at 90 days:

• The team works in HubSpot for sales and marketing activity, with no spreadsheet or notes system running alongside it.
• The pipeline shows where deals are now, not where they were at last week's meeting.
• Leadership reads the HubSpot dashboards themselves, with nothing assembled in Excel beforehand.
• When someone asks where a lead came from, the CRM answers.
• When something has to change, such as a new workflow, a new stage or a new starter, there is a capable internal owner or a support partner who already knows the setup.

If any of these is not true, the implementation has not finished. A good provider knows it and writes a post-launch review into the scope up front.

Frequently asked questions

What are the steps of a CRM implementation? Write down what the new system has to do, choose the platform, clean the data and name the team, define success in numbers, get the users' agreement, budget for the dip, leave room for growth, roll out in stages, assess against your numbers, then revise and go live in full.

How long does a CRM implementation take? With HubSpot, a first CRM off spreadsheets usually takes four to six weeks. A migration from another CRM with integrations usually takes eight to twelve weeks.

What is the most common reason a CRM implementation fails? Moving the old mess into the new system. Every field, pipeline and habit comes across, so the new CRM has the old problems within weeks. Decide what to keep, fix or leave behind before anything is imported.

Should you run the old and new CRM at the same time? For a short crossover only, with the old system read only. Then switch it off and keep a full export as the archive.

Who should own the CRM after go-live? One named person inside the business, with the authority to approve changes. Without an owner, a new CRM drifts back to the state of the old one.

Who owns the code a CRM implementation partner writes? In Australia, IP a contractor creates belongs to the contractor unless the contract says otherwise. Workflows and properties built inside your own portal live in your account, so they stay when a partner leaves. Custom code, integrations and themes can sit outside it, so get those assigned to you in writing before the build starts.

The question worth asking before any of it

If you migrated tomorrow and every record came across cleanly, what would still be broken?

If you can answer that in one sentence, the answer is usually a process problem, and a new CRM will hold a broken process just as faithfully as the old one did. Fixing it first is cheaper than migrating it. That is most of what our RevOps and HubSpot work turns out to be.

So: what is on your list, and which of it is actually the software's fault?