What a Salesforce data migration actually costs in Australia

If you are trying to budget a Salesforce data migration cost and every vendor is giving you a different answer, the vendors are not necessarily being evasive. They genuinely do not know yet. Nobody can price a data migration accurately before they have looked inside the source org, counted the objects and fields, and found out how bad the data is. Anyone who quotes you a firm number in the first meeting is either guessing, padding heavily to cover the guess, or planning to recover the difference through variations later.

This piece will not give you an Australian average, because there isn’t an honest one to give. Published implementation ranges exist overseas and they vary so enormously that quoting them here would mislead you more than help you. What this piece does instead is show you the drivers that actually move the number, so you can build your own estimate, sanity-check a proposal, and tell the difference between a vendor who has thought about your data and one who has thought about your budget.

Why nobody can quote a Salesforce data migration cost up front

A data migration is not a fixed quantity of work. It is a fixed quantity of decisions, and each decision has a variable amount of work hanging off it. The question “how much does it cost to move our data to Salesforce” is structurally similar to “how much does it cost to renovate a house” asked before anyone has opened a wall.

The largest single driver, in the nonprofit world at least, is that the source and target data models often do not agree with each other. Moving from NPSP to what Salesforce now calls Agentforce Nonprofit (renamed from Nonprofit Cloud in December 2025) is not a copy exercise. NPSP’s Household Accounts and Contacts pattern, Person Accounts, Program Enrollments and Benefit Disbursements are genuinely different shapes. Every record that crosses has to be re-homed, and somebody has to decide where. That decision work is the cost. We wrote about the model differences in more detail in our NPSP to Agentforce Nonprofit migration guide.

One real number, and what it does and does not tell you

We can give you one honest anchor: a completed engagement, billed transparently on a timesheet, for an Australian community-care provider moving from NPSP to Nonprofit Cloud alongside their implementation partner.

One hundred and forty-nine hours took that project through to the initial production migration. That split 94 hours of discovery, mapping and QA against 55 hours of production migration and data loads. Further delta loads and post-go-live work followed as staff moved across in cohorts.

What was inside those hours: the Contact object alone carried 314 fields. 17,248 legacy tasks were converted. 201 risk assessments with 4,645 responses loaded with zero failures. 2,313 people, 625 organisations and 2,097 cases were reconciled. The full write-up is in the case study.

Note the ratio, because it is the most transferable thing here: roughly nine hours of thinking for every five hours of loading. Buyers routinely assume the reverse. If a proposal in front of you is weighted heavily towards execution with a thin discovery phase, that is not efficiency, it is deferred cost.

What this number does not tell you is what your migration costs. A different org, with different history, different customisation and a different appetite for archiving, will land somewhere else entirely. Use the anchor to understand the shape of the work, not to set your budget.

The drivers that actually move the number

Work through these honestly and you will have a better estimate than most quotes will give you.

Objects and custom fields. Count them. Not the standard ones, the populated ones. Three hundred and fourteen fields on a single object is not unusual in an org that has been in use for a decade, and each one needs a mapping decision, a transformation rule or an explicit decision to drop it.

History versus archive. How many years are genuinely coming across? Every organisation says “all of it” until someone prices it. Deciding that closed cases older than five years live in a read-only archive rather than the new org is frequently the single largest cost reduction available, and it is a decision only you can make.

Data quality and duplicates. Duplicates do not migrate cleanly, they migrate twice. Whether you clean before or after migration is a real choice with real cost consequences, and cleaning in the legacy system is usually cheaper because your staff already know which record is the right one.

Custom objects with no natural home. Every custom object that maps neatly to a target object is cheap. Every one that does not is a design conversation, a build, and a test cycle. These are where estimates blow out.

Reporting and integrations. Reports and dashboards do not migrate. Integrations very often need rebuilding against the new model. If a quote covers data only, ask explicitly who is rebuilding the reports your board sees every month, because someone has to.

Rehearsal runs. You will not load production once. You will load a sandbox, find problems, fix mappings and load again. The number of rehearsals is a genuine line item, and cutting it is how failed migrations happen.

Hard cutover versus staged. A hard cutover is cheaper. A staged migration with delta loads, where cohorts of staff move across while the old system keeps running, costs more because you are effectively running two systems and reconciling them repeatedly. For a service provider that cannot stop delivering services on a Monday morning, it is worth every dollar. We have written separately on when a staged cutover is the right call.

How much mapping your own team can do. If your staff can answer “where should this field go” without a consultant reverse-engineering it first, your cost drops materially. This is the most controllable variable you have.

Training and post-go-live support. Budget for it explicitly. It is not migration cost, but it is migration-shaped, and it lands in the same month.

Sign-off speed. Who approves the mapping decisions, and how fast do they respond? A single decision-maker on leave for two weeks is a genuine schedule driver, and on time-and-materials it is a genuine cost driver.

Our NPSP data migration checklist walks through the discovery questions in sequence if you want to do this exercise properly before you approach anyone.

Fixed price versus time and materials, honestly

Fixed price protects you when the scope is genuinely knowable, which in practice means after discovery, not before it. A fixed price for the load phase, quoted once the mapping is signed off, is a reasonable thing to ask for and a reasonable thing for a vendor to offer.

A fixed price for the whole migration, quoted before anyone has profiled your data, is a bad deal for you. The vendor must price their worst case, so you pay a risk premium for uncertainty that is largely yours. Worse, it puts the vendor’s interest directly against yours on every ambiguous decision, and you will spend the project arguing about what was in scope.

Time and materials is uncomfortable because it is uncapped, but it is honest. The way to make it safe is not to convert it to fixed price, it is to cap it: a not-to-exceed for discovery, a written estimate for the load phase before the load phase starts, and weekly burn reporting against the estimate. That is roughly how the engagement above was run, and it is why the hours could be published at all.

Questions to ask any vendor quoting your migration

• How many hours of your estimate are discovery and mapping, and how many are loading?
• How many rehearsal runs are included, and what happens if we need another?
• Who is responsible for deciding where an unmapped custom object goes, you or us?
• Is reporting rebuild in or out of scope? Integrations?
• What is your reconciliation method, and what evidence will we get that every record arrived?
• If we archive five years of history instead of migrating it, how much does your number move?
• Which parts of this would you fix-price today, and which would you not, and why?

Red flags in a quote

A firm total with no discovery phase. A discovery phase that is suspiciously small relative to the build. No mention of rehearsals, reconciliation or failure handling. Silence on reporting and integrations. A line saying “data cleansing as required” with no definition of required. And a manufactured deadline: NPSP feature development ended in March 2023, but NPSP is still supported and Salesforce has published no retirement date. Migration urgency is a choice you are making for your own reasons, not a deadline someone is imposing on you. Any vendor using retirement as a closing tactic is telling you something about how they will behave later.

If you want a second opinion on a quote in front of you, or a discovery-only engagement that gives you a defensible number before you commit to a build, that is a conversation we are happy to have. Get in touch and tell us what you have been quoted, and we will tell you what we would want to look at before believing it.