Custom CRM Cost: Budget for Build, Migration and Support

Custom CRM cost depends on what staff need to do, which customer history must remain usable and what other software the system must connect to. A contact database and a working sales system with imported history, controlled access and reliable accounting updates are different projects, even if both quotes say “CRM”.

For an attributable planning reference, IL Goldberg’s 2026 US price guide gives indicative estimates of US$25,000 to US$50,000 for one department and one core workflow, US$50,000 to US$120,000 for multiple departments and integrations with migration and reporting, and US$120,000 to US$250,000 or more for operations-wide scope.

These are one development supplier’s published estimates, not an independently established market average. They describe US pricing and broad project categories, so they should not be treated as UK quotes or converted into pounds and assumed to apply locally. Their useful message is that the scope behind the number matters more than the label.

To set a defensible budget, ask suppliers to price the same first release, inspect representative customer records and separate launch costs from ongoing commitments.

What should a custom CRM budget cover?

A production-ready CRM budget needs to cover more than screens for customers and deals. It should account for understanding the sales process, designing the records and permissions, building and testing the system, moving agreed data, training staff and supporting launch.

Ask for the estimate in three parts:

• Definition and investigation: workflow mapping, source-data inspection, integration checks and acceptance criteria.
• Delivery and launch: design, development, testing, migration rehearsals, training, deployment and launch support.
• Ongoing operation: hosting, backups, monitoring, maintenance, third-party charges and an agreed support arrangement.

Some suppliers combine these activities into one price. That can be reasonable, provided the deliverables and exclusions are explicit. A low build figure tells you little if migration, testing and launch support remain unpriced.

For a custom software build, the first release should complete a useful business process. Staff should be able to receive an enquiry, find the right customer, progress the opportunity and hand it over without maintaining an unofficial second system.

An illustrative CRM brief suppliers can actually estimate

The following is a fictional scope example, not a priced project or client result. Consider a small commercial maintenance business with one sales team. Customer details sit in a spreadsheet, deal progress lives in another, and staff refer to an older CRM for notes and attachments.

Its proposed first release includes company and contact records, linked sales opportunities, follow-up tasks and two defined workflows: new contracts and renewals. Sales staff can edit assigned accounts; a manager can reassign accounts and see all deals. An administrator controls exports and user access.

The business also wants staff to see selected email activity and create an accounting customer after a deal is won. It does not need a customer portal, a replacement accounting system, offline working or a separate mobile app.

That brief is more useful than “a CRM for our sales team”, but several decisions still change the estimate:

• Email: staff manually logging selected messages is a different requirement from automatically capturing correspondence and matching it to customers.
• Accounting: creating a customer once is narrower than keeping addresses, invoice status and payment history updated in both systems.
• History: importing open opportunities and recent notes differs from preserving every old attachment and its relationship to a contact, company and deal.
• Access: hiding unassigned accounts requires different testing from allowing everyone to see all customers but limiting who can edit them.

A sensible initial proposal would price the agreed workflow, define each connection precisely and make the migration allowance conditional on inspecting sample records. It should list optional history, extra reports and broader integrations separately rather than burying them in assumptions.

Which CRM requirements change the estimate?

Customer records and their relationships

A customer may be a company with several sites, multiple contacts and several active deals. One contact might work across different companies. The supplier needs to know which relationships staff must see and preserve.

Count the types of records and the links between them, not only the fields on a contact form. Quotes should state whether they include companies, people, sites, deals, activities, documents and any business-specific records.

Sales processes and permissions

Two sales pipelines may share stages but require different actions. A renewal might depend on an existing contract date, while a new enquiry needs qualification and approval. Describe what must happen at each stage, who does it and what prevents a deal progressing.

Permissions need similar precision. “Sales user” does not explain whether someone can view another salesperson’s customers, download attachments, export the database or delete notes. These rules affect development and acceptance testing.

Reports and connected software

A list of open deals is relatively easy to define. A historical forecast showing what the pipeline looked like at each month-end requires the system to retain the right changes over time. Specify the decisions each report supports and show an example of the expected output.

For every connection, state which system creates the record, which fields move, which direction they move and when. Then ask what happens if the other system is unavailable or rejects an update. A useful estimate includes a way to find failed updates, correct them and retry without creating duplicate customers.

If connected software accounts for a large part of the quote, this guide to what an API integration quote should include gives a more detailed comparison checklist.

Price migration by usable history, not contact count alone

Do not agree a fixed migration scope until the supplier has tested a representative sample of your customer history.

A clean list of names and email addresses does not reveal whether notes retain their authors and dates, attachments can be opened, or deals still belong to the correct customers. Preserving those links can require more work than importing the contact list.

Salesforce’s CRM migration guidance identifies accounts, opportunities, activities, notes, documents, permissions and integrations among possible migration components. It also recommends data auditing and mapping, sample import testing, backups and validation of records, relationships and system behaviour.

As a procurement safeguard, ask the supplier to test a sample deliberately chosen to include difficult records:

• A company with several contacts and multiple deals.
• Duplicate contacts with conflicting details.
• Notes with dates, authors and formatting.
• Attachments in the formats staff actually use.
• Closed, inactive and incomplete records.
• Records whose original owner has left the business.

The output should be a mapping of old fields to new fields, examples of imported records, a list of exceptions and an explanation of anything that cannot be preserved. Agree who decides which duplicate record wins and who fixes missing information.

Separate live customer history from searchable archive material

Not every historical record needs to become an editable record in the new CRM. Decide what staff need during a live customer conversation, what they consult occasionally and what they no longer need, subject to your retention obligations.

In the fictional maintenance business, current contacts, open deals and relevant service notes might belong in the live system. Older closed opportunities and superseded documents could remain in a searchable, access-controlled archive if staff can still find them when needed.

An archive is a scoped deliverable too. Define how people search it, who can access it, how it is backed up and whether it depends on keeping the old software subscription. Moving everything into an inaccessible export is not a useful archive.

Agree how the move will be checked and recovered

The quote should include a migration rehearsal and reconciliation: checking record counts, important field values, attachments and links between records. Counts alone cannot prove that the history is usable.

Before launch, name who owns the source backup, when staff stop changing old records, how late changes are captured and who authorises the switch. Define the conditions for returning to the old system and how any new entries would be preserved if that happens.

A worksheet for comparing CRM quotes

For each item below, record included, excluded or provisional, followed by the supplier’s assumption, the acceptance check and any separate charge. Use the same worksheet for every proposal.

• Records: customer, contact, site and deal types; mandatory fields; relationships; search and duplicate handling.
• Daily work: enquiry capture, pipeline stages, tasks, reminders, approvals and handovers.
• Access: visibility by role or assigned record; editing, deletion, export and administrator rights.
• History and migration: source systems, sample inspection, cleanup responsibility, notes, attachments, archives, rehearsals and failed-record handling.
• Connections: systems and fields, update direction, matching rules, failure alerts, retries and support ownership.
• Reports: agreed examples, calculation rules, filters and any need for historical snapshots.
• Acceptance testing: named staff testers, realistic test records, agreed pass criteria and responsibility for correcting defects.
• Launch: training, documentation, deployment, source backups, cutover, recovery and launch support.
• Ownership and exit: access to code, data exports, hosting accounts and credentials; documentation needed by a replacement supplier.
• After launch: warranty terms, maintenance, response arrangements, backups, monitoring and separately charged changes.

Compare the price of completing the same accepted scope, rather than ranking the headline totals. If one quote includes imported attachments and tested accounting updates while another includes neither, request a revised scope before choosing.

Ongoing costs and sensible ways to reduce the first release

Ask for recurring costs in currency amounts with their billing periods and assumptions. These may include hosting, storage, backups, monitoring, email services, connector licences and support. Identify which accounts your business pays directly and which charges pass through the supplier. Where third-party licences are proposed, check the chosen plan and usage limits against the provider’s current official pricing.

Distinguish correcting a defect against agreed acceptance criteria from paying for a new feature. Also establish who maintains integrations when connected software changes and who handles a failed backup or unavailable system.

To reduce initial custom CRM development cost, narrow the work staff must complete rather than removing the checks that make it dependable. Start with one team and a defined workflow, defer optional reports and portals, and decide which history can stay in an archive. Do not cut migration validation simply to make the proposal fit.

For the fictional maintenance business, a configurable CRM deserves consideration if it can handle the two pipelines, access rules and accounting handover without awkward workarounds. Buying would still require configuration, migration and staff training. A custom build would add responsibility for maintaining the application itself.

The recommendation changes if a demonstrated requirement cannot be met sensibly in the configurable product, such as staff needing to manage several customer sites and contract-specific approvals in one working view. Test that requirement before committing to a build. A smaller custom connection around an existing CRM may be sufficient.

I would first inspect a representative slice of the existing customer records and walk through one real sale from enquiry to handover. That gives suppliers something concrete to estimate and exposes the assumptions most likely to turn a cheap CRM quote into an expensive migration.