Salesforce Data Migration Best Practices: A Practical Guide for NZ Businesses

Moving data into Salesforce — or between Salesforce orgs — is one of the most consequential projects your business will undertake. Get it right, and your team hits the ground running with clean, structured data from day one. Get it wrong, and you spend months cleaning up the mess while your team loses confidence in the platform.

At SaaSkool, we have managed data migrations for businesses across New Zealand ranging from a few thousand records to several million. The technical execution matters, but the planning, validation, and governance around the migration is what separates success from disaster.

This guide covers what we have learned from doing this work repeatedly. It is written for NZ and Australian businesses, with specific attention to the compliance and practical considerations relevant to our part of the world.

Why Data Migration Deserves More Respect

Most organisations underestimate data migration. They treat it as a checkbox exercise — export from the old system, import into Salesforce, move on. This approach almost always leads to problems.

Here is why migration is harder than it looks:

Data models rarely align. Your old CRM structures data differently from Salesforce. Fields do not map one-to-one. Relationships between records are stored differently. Picklist values do not match.
Data quality issues are hidden. Your source system has been accumulating bad data for years — duplicates, incomplete records, outdated information, inconsistent formatting. Migration is when these issues become visible and painful.
Business logic needs translating. The way your old system handled lead conversion, opportunity stages, or account hierarchies may not translate directly into Salesforce concepts.
Volume creates complexity. Migrating 500 contacts is straightforward. Migrating 500,000 records with attachments, activities, and cross-object relationships requires careful orchestration.

The good news is that with proper planning, all of these challenges are manageable. Let us break down the process.

Phase 1: Planning and Assessment

Before you touch any data, invest time in thorough planning. This phase typically takes 20-30% of the total migration effort, and it is worth every hour.

Define Your Migration Scope

Not all data needs to migrate. This is one of the most liberating realisations in the process. Ask yourself:

What data is actively used today? Records that have not been touched in three or more years may not need to come across.
What data is legally required to retain? NZ businesses have specific retention obligations depending on industry. Tax records, employment records, and certain financial data have mandatory retention periods.
What data is the source of truth? If the same data exists in multiple systems, decide which version is authoritative before migration.
What can be archived instead of migrated? Historical data that you need to keep but will rarely access can often be archived separately rather than cluttering your new Salesforce org.

We typically recommend that NZ businesses create a simple matrix listing every data object, its record count, its business importance, and the migration decision (migrate, archive, or discard).

Map Your Data Model

Data mapping is the most critical technical exercise in the entire migration. For each object you are migrating, you need to document:

Source field to target field mapping — Which field in your old system corresponds to which field in Salesforce?
Data transformations — Do values need to be reformatted, split, merged, or converted? For example, NZ phone numbers might need standardising to include the +64 country code.
Default values — What happens when a source field is empty but the Salesforce field is required?
Picklist value mapping — If your old system uses "Prospect" and Salesforce uses "Qualified Lead", how do you translate?
Relationship mapping — How do parent-child relationships (like accounts and contacts) get preserved during migration?

Document this mapping in a spreadsheet that both technical and business stakeholders can review. This document becomes your single source of truth throughout the project.

Establish Data Quality Rules

Before migration is the ideal time to define and enforce data quality standards. These rules should cover:

Required fields — What must be populated for a record to be considered valid?
Format standards — How should phone numbers, addresses, and email addresses be formatted?
Naming conventions — How should account names be structured? Title case? Full legal name? Trading name?
Deduplication criteria — What constitutes a duplicate? Exact email match? Company name similarity?
NZ-specific considerations — NZBN (NZ Business Number) for companies, IRD numbers if relevant, Charities Services registration numbers for nonprofits

Phase 2: Data Preparation

With your plan in place, the next phase is preparing your data for migration. This is where you transform raw source data into clean, Salesforce-ready datasets.

Extract and Profile Your Source Data

Pull a complete export from your source system and profile it thoroughly. You are looking for:

Completeness — What percentage of records have key fields populated?
Consistency — Are the same values represented in the same way across records?
Validity — Do email addresses have valid formats? Do dates make sense? Are numeric fields within expected ranges?
Uniqueness — How many duplicate records exist?

Tools like Excel, Google Sheets, or dedicated data quality platforms can help with profiling. For larger datasets, Python or SQL-based analysis may be more practical.

Clean Before You Migrate

There is a golden rule in data migration: never migrate dirty data. It is far easier and cheaper to clean data before it enters Salesforce than to fix it afterwards.

Common cleaning tasks include:

Deduplication — Identify and merge duplicate records. For NZ businesses, pay particular attention to company records that may appear under both their trading name and legal entity name.
Standardisation — Normalise phone numbers (NZ mobiles should be +64 2X XXX XXXX format), addresses (use NZ Post address format), and email addresses (lowercase).
Enrichment — Fill in missing data where possible. NZBN lookups can help complete company information. Companies Office data can verify legal entity details.
Validation — Verify email addresses are deliverable, phone numbers are callable, and postal addresses are valid. NZ Post offers address validation services that can help.
Archival — Remove records that did not make the cut during scoping. Store them separately in case they are needed later.

Prepare Your Salesforce Org

Your target Salesforce org needs to be ready to receive the data. This means:

Custom fields are created — Every mapped target field must exist before you start loading data.
Picklist values are configured — All expected values must be present in picklist fields.
Validation rules are considered — You may need to temporarily deactivate certain validation rules during migration, then reactivate them afterwards. Document which rules you deactivate and why.
Record types are set up — If you are using record types, ensure they are configured before migration.
Automation is paused — Workflow rules, process builders, flows, and triggers can fire during data loading, causing unexpected results. Deactivate non-essential automations during migration.

Phase 3: Migration Execution

With clean data and a prepared target org, you are ready to execute. But do not go straight to production.

Choose Your Migration Tool

The right tool depends on your volume and complexity:

Salesforce Data Loader — Free, handles up to 5 million records, supports all standard and custom objects. Good for straightforward migrations but requires technical comfort with CSV files and API concepts.
Dataloader.io — Cloud-based alternative with a more user-friendly interface. Free tier supports up to 10,000 records per month. Paid tiers handle more volume.
Salesforce Data Import Wizard — Built into Salesforce, handles up to 50,000 records. Best for simple imports of accounts, contacts, leads, or solutions.
Jitterbit, Informatica, or MuleSoft — Enterprise-grade ETL tools for complex, large-volume migrations. Overkill for most NZ SMBs but essential for enterprise-scale projects.
Custom Apex scripts — For migrations with complex transformation logic that cannot be handled by configuration alone.

For most NZ small-to-medium businesses, Data Loader or Dataloader.io covers 90% of requirements.

Follow the Correct Loading Order

Salesforce has a strict dependency hierarchy. Records must be loaded in the right sequence to maintain relationships:

Users — Load or activate all users first, as they will be referenced as record owners and assignees.
Accounts — Parent accounts first, then child accounts (if using account hierarchy).
Contacts — After accounts, so they can be associated with the correct account.
Opportunities — After accounts and contacts, with correct account associations.
Activities (Tasks and Events) — After the records they relate to (accounts, contacts, opportunities).
Cases — After accounts and contacts.
Custom objects — In dependency order, with parent objects before child objects.
Attachments and files — Last, as they attach to existing records.

Skipping this order or trying to load everything simultaneously is a recipe for failed inserts and broken relationships.

Run a Trial Migration First

Always — without exception — run a full trial migration into a Salesforce sandbox before touching production. This trial should:

Use the complete dataset, not a sample
Follow the exact same process you plan to use in production
Include all data transformations and mappings
Be validated by business users, not just the technical team

The trial migration will reveal problems that no amount of planning can anticipate. Missing picklist values. Truncated fields. Character encoding issues with macrons in Maori place names (a common issue for NZ migrations). Relationship mismatches. Records that fail validation rules.

Fix everything the trial reveals, then run a second trial if needed. Only proceed to production when a trial completes cleanly and business users confirm the data looks correct.

Execute the Production Migration

When it is time for the real thing:

Choose a low-activity window. For NZ businesses, a Friday evening or weekend is usually best. This gives you time to validate before Monday morning.
Disable non-essential automations. As planned during preparation.
Load data in the correct order. Follow your documented sequence.
Monitor for errors. Data Loader produces error logs. Review them in real time, not after the fact.
Preserve external IDs. If your source system has unique identifiers, store them in a custom field in Salesforce. This makes it possible to trace records back to the source and simplifies any future corrections.

Phase 4: Validation and Post-Migration

The migration is not complete when the last record loads. Validation is what separates a migration from a data dump.

Validate Record Counts

Compare record counts between source and target for every object. If you extracted 12,450 contacts and only 12,311 loaded successfully, you need to investigate those 139 failures.

Validate Data Accuracy

Spot-check individual records across every object type. Pull a random sample and verify:

Field values match the source (accounting for any planned transformations)
Relationships are intact (contacts belong to the right accounts, opportunities are linked correctly)
Dates have not shifted due to timezone conversion (a common issue when migrating from systems that store dates differently)
Currency values are correct and in NZD where expected

Validate Business Processes

Run through your key business processes end-to-end using migrated data:

Can a sales rep view their accounts and pipeline correctly?
Do reports and dashboards show accurate numbers?
Do automations fire correctly with the migrated data?
Can customer service look up a customer and see their full history?

Reactivate Automations

Turn your automations back on one by one, testing each to ensure it works correctly with the migrated data. Do not reactivate everything simultaneously — if something breaks, you want to know exactly which automation caused it.

NZ and AU Compliance Considerations

Data migration has specific compliance implications for businesses operating in New Zealand and Australia.

Privacy Act 2020 (New Zealand)

The Privacy Act governs how NZ organisations collect, store, use, and disclose personal information. During migration:

Information Privacy Principle 5 (Storage and Security) — You must ensure personal information is protected against loss, unauthorised access, and misuse during the migration process. This means encrypting export files, securing transfer channels, and limiting who has access to migration datasets.
Information Privacy Principle 8 (Accuracy) — You should take reasonable steps to ensure personal information is accurate before migrating it. Migration is an ideal opportunity to verify and correct records.
Information Privacy Principle 9 (Retention) — Do not migrate personal information you no longer need. If records relate to individuals you no longer have a relationship with and no legal obligation to retain, consider whether migration is appropriate.
Cross-border considerations — Salesforce data may be stored in overseas data centres. Ensure your Salesforce contract addresses data sovereignty requirements and that you can meet your obligations under IPP 12 (Disclosure of personal information outside New Zealand).

Australian Privacy Act

If you operate in Australia or hold data about Australian residents:

Australian Privacy Principle 8 requires that before disclosing personal information to an overseas recipient (which may include storing data on US-based cloud infrastructure), you take reasonable steps to ensure the recipient complies with the APPs.
Data breach notification obligations under the Notifiable Data Breaches scheme apply to migration-related incidents.

Practical Compliance Steps

Document your migration process, including what data was migrated, when, by whom, and what safeguards were in place
Securely delete migration staging files (CSVs, exports) after the migration is validated
Update your privacy policy if the migration changes how or where personal information is stored
Ensure your Salesforce org security settings align with your privacy obligations

Common Pitfalls and How to Avoid Them

After dozens of migrations, here are the mistakes we see most often:

Skipping the trial migration. This is the single most common cause of migration failure. It feels like it saves time. It does not. It costs time, and usually a great deal of stress.

Migrating everything. The instinct to bring every record across is understandable but counterproductive. Migrate what you need. Archive the rest.

Ignoring data ownership. Every Salesforce record has an owner. If you do not map owners correctly, records will default to the user running the migration, creating a mess of ownership that takes weeks to untangle.

Forgetting about attachments and files. Attachments, documents, and files are often an afterthought. They have their own migration challenges — size limits, API call consumption, and the distinction between Attachments (legacy), Content Documents (modern), and Files.

Not communicating with your team. Your users need to know when migration is happening, what to expect, and who to contact if something looks wrong. A brief communication plan prevents a flood of support requests on Monday morning.

Timezone and locale issues. NZ is UTC+12 (or UTC+13 during daylight saving). Date and datetime fields can shift during migration if timezone handling is not managed carefully. Always verify date accuracy in your trial migration.

Working with SaaSKool on Your Migration

Data migration is one of the areas where having experienced guidance makes the most tangible difference. The cost of getting it wrong — in rework, lost productivity, and damaged trust in the platform — far exceeds the cost of getting proper help upfront.

At SaaSkool, we work with NZ and Australian businesses to plan, execute, and validate Salesforce data migrations of all sizes. Whether you are moving from a spreadsheet, another CRM, or a legacy system, we bring the methodology, the tools, and the local knowledge to get your data into Salesforce cleanly and compliantly.

If you have a migration on the horizon, reach out for a no-obligation conversation about your specific situation. We will give you an honest assessment of the complexity, the timeline, and what it will take to get it right.