CRM data migration checklist for SuiteCRM and EspoCRM

How to use this CRM data migration checklist

This checklist is for a sales or finance team moving accounts, contacts, opportunities, activities and attachments out of Salesforce, HubSpot or a legacy CRM and into a self-hosted SuiteCRM or EspoCRM instance without losing history or exposing records to the wrong people. The move is safe only when every data type has a named owner, a mapping decision and a test that shows the result. The checklist runs in order: scoping the objects and volumes, mapping fields and owners, setting duplicate rules and import modes, running trial imports, mapping permissions, and finishing with post-migration checks and sign-off. Each requirement carries a verification method, such as comparing record counts per object, sampling opportunity amounts against the source report, or confirming that a salesperson sees only their own territory after login.

Treat the list as a starting point, not a substitute for testing in your own environment. Your source export, custom objects, email integration and identity provider will differ from any generic example, so the trial import on a staging instance is where the checklist becomes evidence. Confirm the target version before you start: SuiteCRM 8 and EspoCRM have different import tooling and data models, and the SuiteCRM 7 to 8 path is a migration rather than an upgrade, as described in the SuiteCRM migration documentation. Ask your implementation partner to show the trial results, the exceptions list and the rollback plan in writing, and keep the source system read-only until your business owner signs off the final load.

Which records, fields and relationships must move intact

This table lists the CRM objects and attributes that must survive a move into SuiteCRM or EspoCRM, with why each matters for sales reporting and how to verify it. Use it to agree scope with the implementation partner before the first trial import, and treat each row as a pass or fail check in the trial and final cutover.

Requirement	Why it matters for sales reporting	How to verify after import
Accounts and contacts, with parent links	Pipeline and activity reports roll up by account. A contact detached from its account breaks territory and ownership views.	Reconcile record counts per object against the source export, then sample 20 accounts and check each contact still points to the right parent.
Opportunities with amount, close date, stage and owner	Forecast, win rate and stage aging reports depend on these exact fields. Currency and close date errors distort every total.	Compare totals by stage and owner between source and target reports, and check 20 opportunities field by field.
Stage mapping from source to target pipeline	Source stages rarely match target stages one to one. Unmapped or merged stages change conversion rates and historical trends.	Confirm a written stage map signed off by sales leadership, then check that every source stage value lands in a mapped target stage.
Picklist values and data types	Dates stored as text, or picklist labels that do not exist in the target, cause silent blanks or failed filters in reports.	Export distinct values per picklist from both systems and confirm each source value has a target value or an approved default.
Custom fields and their history rules	Industry or deal-specific fields often drive the most-used reports. Dropping them removes context that teams rely on daily.	Build an inventory of custom fields with usage counts in the source, then confirm each retained field is populated in a sample of records.
Activities linked to accounts, contacts and opportunities	Call, meeting and task history supports activity reports and rep performance reviews. Orphaned activities disappear from record timelines.	Count activities per type and parent object in source and target, and check that 20 sampled opportunities show their full activity history.
Notes and attachments with their parent record	Contract and proposal files are often the only evidence of commitments. Files that import without a parent link are hard to find later.	Confirm file counts and total size against the source, then open a sample of attachments from several objects to check they resolve to the correct record.
Created and modified dates, and original owner	Cycle time, aging and audit questions depend on original timestamps. Imports that stamp every record with the migration date erase this history.	Check that created dates match source values for a sample of records, and confirm the import mode preserves them as intended.
Volume by object and reconciliation sign-off	Volume gaps are the earliest sign of truncated imports, duplicates or skipped batches. A documented baseline makes later disputes easier to resolve.	Record counts for every object in a dated reconciliation sheet, with differences explained and approved before cutover.

The migration sequence from export to cutover

This sequence turns an export from Salesforce, HubSpot or a legacy CRM into a tested, reconciled dataset in SuiteCRM or EspoCRM, with every record count, owner and permission accounted for before production users log in. Each step closes with a written output so the cutover decision rests on evidence rather than memory.

Freeze the source and export data
Agree a cutoff time with sales operations and stop edits in the source system, or record a final delta window if the business cannot pause. Export accounts, contacts, opportunities, activities, attachments and users, along with their relationship keys, and store the exports in an encrypted location with access logged. The step is done when the export files have checksums, row counts per object match the source reports, and the freeze time is written into the migration plan. If you are moving from SuiteCRM 7 to 8, this is a migration with its own documented steps rather than a file import, so start from the SuiteCRM migration documentation, bring the 7 instance to the latest 7.14.x or later first, and take full file and database backups before anything else.
Inventory custom objects and fields
List every standard object, custom object, picklist value, required field, formula, workflow and integration that reads or writes CRM data, and note which ones the business still uses. Your partner and your sales operations lead should review the list together, because most migration gaps come from fields that exist in the source but appear in no report. The output is a signed inventory that marks each item as migrate, transform, merge into another field or retire, with an owner for each decision.
Build the field map
Map each source field to a target field in SuiteCRM or EspoCRM, including data type, length, picklist translations, currency, time zone and date format conversions. Record the transformation rules for values that do not translate directly, such as multi-select picklists or activity types that have no target equivalent. Keep the map in version control so that every later import run uses the same rules. The step is complete when each in-scope field has a target, a transformation or an explicit retirement decision, and the business owner has approved the map.
Set duplicate rules and matching keys
Define how the system decides that two accounts or contacts are the same, for example by normalized email address, domain, tax identifier or external ID, and decide which record wins when duplicates merge. Decide whether duplicates are merged, skipped or flagged for review, and document who reviews the flagged set. Test the rules against a sample export that includes known duplicates. The output is a duplicate policy with example matches and non-matches, approved by the sales lead.
Run a trial import on staging
Load the mapped data into a staging copy of the target system, which should match production configuration, including roles, workflows and authentication. Use the import tools in the target platform to run a small batch first, then the full dataset, and log every rejected row with its reason. Review the EspoCRM import documentation or the SuiteCRM import guidance for the import modes available in your version, and confirm that the chosen mode creates, updates or skips records as intended. Repeat the trial until rejected rows are either fixed or explicitly accepted. Keep staging backups from each run so you can rerun from a known point.
Reconcile counts and sample records
Compare record counts per object between the source export and the staging import, then account for every difference using the duplicate log, the rejection log and any intentional exclusions. Pick a sample of records across owners, stages and record ages, and check that field values, relationships, activity links and attachment counts match the source. The step is done when each object has a reconciliation sheet where every gap has a reason and a sign-off from the business owner.
Map owners, teams and permissions
Map each source user to a target user, then assign ownership of accounts, contacts and opportunities to match the sales territory design. Set teams, roles and record-level access so that people see the same records they saw before, and confirm that API users or integration accounts have only the permissions they need. If single sign-on is part of the target design, test that identity groups map to the correct teams before go-live. The output is an ownership and access matrix signed by the sales and security leads, plus a test log showing that sample users can see and edit the records they should.
Load production and run post-migration checks
Load production from the approved staging run, using the same map, rules and import mode, then repeat the count and sample reconciliation against the frozen export. Check that scheduled jobs, workflows, email sync and integrations are running, because EspoCRM and SuiteCRM both depend on background jobs that must be scheduled correctly. Verify that backups run and restore correctly on the production system. The step closes when the production reconciliation matches staging, background jobs run without errors, and the team has recorded the results in the cutover log.
Cut over and retain the source archive
Announce the cutover window, reopen the target system to users, and apply the delta from the freeze window if one was agreed. Keep the source system in read-only mode for a period set by your records and retention policy, and store a final archive export with an access log. Confirm with the business owner that the sales team can complete their daily work in the new system before the source is retired. The output is a signed cutover record that names the final counts, the archive location and the date the source was made read-only.

How duplicate rules and import modes decide data quality

Most data quality problems in a CRM migration are created at import time, not later. The choices below decide which records merge, which get skipped, which keep their history and which are logged for review, so settle them on a trial import before the full load.

Matching keys for accounts and contacts

Email, company domain, phone and external IDs each match differently. Email is usually the strongest key for contacts, while domain is weaker for accounts because subsidiaries share it. Decide the order of keys before the trial, and confirm in the EspoCRM import documentation which fields the importer can use to identify an existing record and whether it matches on more than one field. For SuiteCRM, confirm the duplicate check behavior in the import tooling for your chosen version.

Merge, skip or update on import

Each import mode changes existing records differently. Skip keeps the CRM version untouched, update overwrites populated fields with source values, and merge-style behavior depends on what the tool supports. Run a trial import on a staging copy and compare field values for a sample of matched records. Confirm in the import documentation for your version exactly which fields are overwritten and whether blank source values clear existing data.

Activities linked to merged records

Calls, emails, meetings and tasks point to the record they were logged against. When two accounts or contacts merge, those links must follow the surviving record or the history disappears from the timeline. Before importing, export activities with their parent IDs, decide which record survives, and test in staging that activities appear under the surviving record. Ask your implementation partner how activity re-parenting is handled for each source system.

Attachment size and storage limits

Attachments are often the largest part of a CRM migration and the most likely to fail silently. Check the file size limits set in the application and the web server, the free disk space on the target host, and whether files import with their parent records or must be attached in a second pass. Confirm the attachment path and backup scope so restored environments include the files as well as the database.

Keeping source IDs in a custom field

A custom field holding the Salesforce or HubSpot record ID lets you trace any migrated record back to its source, reconcile counts, and re-run an import without creating duplicates. The cost is an extra field to maintain and an index to consider on large tables. Decide whether the field is kept for audit purposes after cutover, and document who can read it, since legacy IDs can help link records across systems.

Logging rejected rows

Every rejected row needs a reason, a source identifier and an owner for correction. Require the import to produce an error file or log for each run, and keep it with the trial and final load records. Review rejects by category, such as invalid email, missing owner or unmapped picklist value, rather than fixing them one by one. Confirm in the EspoCRM import documentation what error output the importer provides for each run.

What differs when leaving Salesforce, HubSpot or a legacy CRM

Salesforce data is organized as standard and custom objects with record types, page layouts and profile-based permissions, so the export is rarely a flat copy of what users see. Accounts, Contacts, Opportunities, Tasks and Events are the core objects, but activity history, attachments and files are stored in different places depending on the org's configuration and Salesforce edition. Teams usually export with the Data Export Service or the Data Loader, and the output must be checked against the object model rather than the screens.

Record types: Opportunities and Accounts often carry several record types, each with its own picklist values, so stage names must be mapped per type before import.
Activity objects: Tasks and Events are separate objects, and email and call logs may sit in activity history with its own retention limits.
Attachments and files: Classic Attachments, Salesforce Files and ContentDocument links use different structures, so confirm which one holds each document.
Owner and sharing: Owner IDs, role hierarchy and sharing rules do not transfer automatically, so user records must be mapped to SuiteCRM or EspoCRM users first.
Custom fields and API names: API names differ from labels, and formula and roll-up fields are recalculated rather than stored.

Ask the Salesforce admin to confirm which objects, record types, activity history and file storage locations are in scope, and request an export that includes the API names and user list.

How to map owners, teams and permissions before the first import

Map record ownership, team membership and role-based access before any data is loaded. An imported account, contact or opportunity without a valid owner can end up invisible to the people who need it or impossible to reassign from the list view, and that problem is hard to see until users start asking where their pipeline went. Start with a complete list of every user in the source system, including inactive accounts, and decide for each one whether they become an active user in the target, map to an existing user, or are retired. Departed users are the most common gap: assign their records to a named placeholder user or to their manager, and record that decision in the mapping workbook so the reassignment is auditable.

Next, translate the source's territories, queues and sharing rules into the target's team model. Teams and roles are not the same thing in SuiteCRM and EspoCRM, so confirm how each handles record visibility before you design the mapping. EspoCRM uses roles that set access levels per entity and teams that group users for record sharing, and it can map identity provider groups to teams when OpenID Connect sign-in is configured. SuiteCRM 8 has its own role, team and access configuration, and its login options (LDAP or SAML) do not replace that model. Ask your implementation partner to show the exact visibility rules for accounts, opportunities and activities in the version you are deploying, and to document any record that a role cannot see after import.

Verify access with test accounts before the production load. Create one test user for each role, team and territory in a staging instance, load a sample of migrated records, and check what each account can see, edit, reassign and export. Include a manager account, a restricted account, a user who owns no records and a user whose records were reassigned to a placeholder. Keep the results in a signed-off checklist, and repeat the check after the final import because owner IDs often change between the trial and the cutover. Confirm with the vendor and your partner how the API authentication used by integrations is scoped, since an integration user with broader access than the business users is a common audit finding.

Security controls to set before data arrives

A CRM migration moves customer records, pipeline history and attachments into a new system before most teams have finished their access model. Set these controls first so that staging copies, exports and the import itself are covered by the same rules as production. Whether the FTC Safeguards Rule applies to your organization is a question for your counsel and compliance lead to confirm.

Restrict the import role

Create a dedicated import role that can run imports and read the target objects, and grant it to as few named people as possible. Keep administrators out of routine import work so that bulk changes to accounts and contacts are traceable to one role. Confirm in the target platform how record-level permissions interact with import, because a role that can create records may still be limited in which owners it can assign. Review the role before each trial import and remove it after cutover.

Sign in through the identity provider

Connect the CRM to your identity provider before any staging user logs in, so that migration reviewers use the same authentication as production. SuiteCRM 8 supports LDAP and SAML, and EspoCRM supports OpenID Connect, LDAP and its own login. Confirm how logout works, since the SuiteCRM SAML configuration does not support IdP-initiated logout, which means an identity provider sign-out does not end the CRM session. Document the fallback login method you keep for administrators.

Enforce HTTPS and encryption at rest

Require HTTPS on every staging and production endpoint, and confirm that the database, file storage and backups are encrypted at rest. Migration staging copies often hold the full customer history and are easy to forget, so they need the same protection as production. The FTC Safeguards Rule at 16 CFR 314.4 addresses encryption of customer information in transit over external networks and at rest. Ask your implementation partner to show where each store is encrypted and who holds the keys.

Scope API users with HMAC

Any integration that writes migrated data, such as a script that loads attachments or syncs an ERP, should run under its own API user with the smallest role that works. EspoCRM documents HMAC as the most secure API authentication method and advises against basic authentication. Issue one key per integration, rotate it after the migration, and record which system used which key. Do not reuse an administrator account for scripted loads.

Set retention and deletion for exports

Migration files, CSV exports and staging databases hold the same personal data as the source CRM, often in more places. Record where each export is stored, who can read it, and the date it must be deleted, and set that date before the first export is created. Include downloaded spreadsheets on laptops and shared drives in the inventory. Confirm with your records and legal owners how long source data must be kept, since that period may differ from the period for the migration copies.

Log every import and admin change

Turn on audit logging before the first trial import so that each batch, its user and its timestamp are recorded. The FTC Safeguards Rule requires covered institutions to log the activity of authorized users, which makes import logs a direct compliance artifact. Keep logs in a location the migration team cannot edit, and confirm which fields the platform records for bulk updates and deletes. Review the log after each trial to catch mapping errors and unexpected owner changes.

Questions to answer after the import

How do I confirm every record count reconciles after a CRM import?

Compare record counts for accounts, contacts, opportunities, activities and attachments between the source export and the target system, and keep the totals in a signed reconciliation sheet. Counts should match after accounting for records you deliberately excluded, such as archived or duplicate rows, and each exclusion should have a written reason. Run the same count query on both sides, including soft-deleted or inactive records where the source system holds them. The data migration lead prepares the reconciliation, and the business owner of each object signs off on the difference column. If a count does not match, do not close the phase until every gap is explained by a rule that was agreed before the import.

Do sampled opportunities keep their stage, amount and close date?

Yes, if a sample check confirms those three fields match the source for a defined set of opportunities. Pick a sample that covers each pipeline, each stage, both open and closed-won or closed-lost deals, and records with currency or multi-currency values. Compare the stage label, the amount in its original currency, and the close date, paying attention to date formats and time zones that can shift a day during import. Record every mismatch and trace it to a mapping rule or a picklist value that did not translate. The sales operations lead usually signs off, with a sales manager reviewing a few deals they know well.

How do I check that activities are attached to the right parent records?

Check that each imported call, meeting, task and email links to the same account, contact or opportunity it was linked to in the source. Activities are the most common place for broken relationships, because the parent lookup depends on an ID mapping that must run in the correct order. Test a set of activities from each parent object type and confirm the related record opens and shows the activity in its timeline. Also check that activity dates, owners and completion status survived the import. The implementation engineer runs the test, and a sales or customer success lead confirms that their working history is intact.

How do I verify that attachments open correctly after migration?

Open a sample of attachments from each parent type and confirm the file opens, the name and size match, and it is linked to the right record. Check large files, unusual formats and files with non-Latin names separately, because storage limits and character encoding often fail there. Confirm the file count and total storage size against the source export, and make sure file permissions in the target system follow the parent record's access rules. Keep a log of files that could not be moved so the team can recover them from the original source before it is retired. The engineer performs the checks, and the records owner signs off.

How do I confirm owners and teams see the correct records?

Log in as a representative user from each team and confirm they see only the accounts, contacts and opportunities they should, and that managers see their reports' records. Compare the owner and team assignments against the approved permission mapping, since owner IDs often fail to resolve if users were created after the import ran. Check that inactive or departed users are handled as agreed, and that record-level access rules match the source. In SuiteCRM and EspoCRM, role and team configuration is what controls visibility, so test each role rather than only the administrator account. The security or CRM administrator and the sales leadership sign off together.

Do reports and dashboards match the totals in the source system?

They should, for the same period, filters and currency basis, and the check is to run the same report in both systems and compare the totals line by line. Start with a few key figures, such as open pipeline by stage, won revenue by quarter and activity counts by owner, because those expose most mapping errors. If a total differs, check whether the source report used a different date field, time zone or currency conversion before assuming the data is wrong. Document each accepted difference with its cause. The reporting owner, usually the sales operations or finance lead, signs off on the reconciliation.

What is the rollback plan if the import fails validation?

A rollback plan defines, before the production import, how to return the CRM to its pre-import state and how long the source system stays available as the system of record. Keep a full database and file backup taken immediately before the import, test restoring it on a staging copy, and record the steps and the person who can execute them. Agree the criteria that trigger rollback, such as a failed reconciliation or broken opportunity history, and decide who has authority to call it. Keep the source CRM read-only or available until the business has accepted the migrated data. The project sponsor approves the rollback criteria, and the engineering lead confirms the restore has been tested.

Who signs off that the CRM migration is complete?

Completion should be signed by named owners for each area, not by the implementation team alone. Typically the data owner signs off record counts, the sales operations lead signs off pipeline history and reports, the security administrator signs off permissions, and the project sponsor accepts the overall result. DeployOpen can prepare the reconciliation evidence, test results and sign-off forms as part of a fixed-scope engagement, but the client's business owners accept the data. Confirm the sign-off roles and acceptance criteria in the written scope before the import begins, so that disputes can be resolved against agreed checks.

How to retain source history after cutover

This sequence keeps a defensible record of the legacy CRM after go-live, so the team can answer history questions, meet its own retention policy and remove temporary copies of migrated data in a controlled way.

Decide the source archive approach
Before cutover, the CRM owner and the compliance lead agree in writing what happens to the legacy system: whether it is kept as a read-only archive, exported to files, or retired after a final snapshot. The decision records which entities, attachments and activity logs are in scope and who approves it. Done means a signed archive decision exists and names the system owner for the archive.
Set the retention period from policy
The organization sets the retention period from its own records policy, not from a vendor default or a number in this guide. Legal, compliance or outside counsel confirms whether any sector rules apply to CRM records, such as communications retention for regulated advisers or broker-dealers, and whether a legal hold is open. Done means the retention period, the owner of each record class and any hold are documented and approved.
Keep the legacy system read-only
The legacy CRM is switched to read-only for users once the target system is live, and the platform team confirms that integrations, scheduled imports and automations no longer write to it. The access period is defined in the archive decision and reviewed by the business owner. Done means a test user cannot edit or delete records and the change is logged in the archive record.
Export final snapshots of source data
Immediately before the final cutover delta, the team exports full snapshots of accounts, contacts, opportunities, activities, notes and attachments, along with users, teams and permission data. Exports are stored in the approved archive location with checksums and an index that maps each file to its source object. Done means a restore test or sample open of each export succeeds and the index is signed off by the data owner.
Verify the archive is complete and readable
The team opens a sample of archived records and attachments, compares record counts against the source report and checks that timestamps, owners and relationships are still interpretable. Gaps are logged with a decision on whether they are acceptable. Done means the reconciliation report shows counts and exceptions and the business owner accepts the archive as the historical record.
Restrict access to the archive
Archive files and any read-only legacy instance are limited to named roles, with access logging turned on where the platform supports it and encryption at rest for stored exports. Sensitive records are reviewed against the organization's data classification and access rules. Done means an access list is approved and the platform team can show who can open the archive and how access is logged.
Delete temporary staging copies
Once the archive and the target system are both verified, the team removes migration staging databases, intermediate CSV files, test imports and copies held by contractors, following the deletion steps in the migration plan. Deletion is recorded with the date, the person who approved it and the storage locations cleared. Done means a deletion log exists and no staging data remains outside the approved archive.
Schedule the archive review
The retention period, access list and read-only status are placed on a recurring review with a named owner, so the archive is checked when policy, staff or systems change and disposed of when the retention period ends and no hold applies. Done means the review date and owner are recorded in the records register and the first review is booked.

How much effort does a CRM data migration take?

What drives the effort of a CRM data migration?

Effort rises with the volume of records, the number of custom objects and fields, the state of the source data, how many source systems feed the new CRM, and how complex the permission model is. A clean export of a few thousand accounts with standard fields is a small job. Duplicate-heavy data, custom Salesforce objects with no SuiteCRM or EspoCRM equivalent, and several legacy systems merged into one target each add mapping, cleansing and testing rounds. Ask any partner to estimate effort by these drivers in writing, listing each source object and the number of records behind it.

Record volume and attachment size
Custom objects, fields and picklist values that need a home
Duplicate rate and data quality across sources
Number of source systems and their export formats
Owner, team and sharing rules that must be reproduced

What do we need to provide for a CRM migration?

The work needs administrator access to the source CRM or export files, a named owner for each business object such as accounts, opportunities and activities, and someone who can sign off field mappings and test results. Sales operations leads usually know which pipeline stages and picklists still matter. Finance or compliance should confirm which closed records and attachments must be kept and for how long. Without these people available on a set schedule, mapping decisions stall and the migration timeline slips. Put these roles and review dates into the written scope before work starts.

Can we migrate CRM data ourselves?

Yes, for a small dataset with clean, mostly standard fields and few owners. A team with a technical administrator can export from the source, map fields in a spreadsheet, and import into a staging instance of SuiteCRM or EspoCRM first. The SuiteCRM migration documentation advises testing on a staging instance and backing up files and the database before any move. Hire outside help when the data has many duplicates, custom objects, several source systems, or strict audit needs, because errors in those cases are hard to reverse and hard to see.

How do trial imports reduce migration risk?

A trial import loads a subset of real records into a staging instance so the team can see how fields, relationships, owners and attachments land before the full run. Each trial should check record counts, lookups between accounts and contacts, owner assignment, date and currency formats, and whether attachments open. EspoCRM's import documentation describes how imports are configured per entity, which makes repeat trials practical. Run at least one trial with the same settings and data scope as the planned production load, and record every defect so the final import is a repeat of tested steps, not a new experiment.

What should a partner quote for a CRM migration include?

A quote should follow from a written scope listing each source system, each object to migrate, the target platform and version, and the record and attachment volumes. It should separate one-time work (discovery, field mapping, deduplication rules, trial imports, cutover, post-migration checks and training on the new data model) from recurring work such as hosting, support and upgrades. Ask for the acceptance criteria, the number of trial rounds included, what happens if a trial fails, and whether retained data is removed from the partner's systems at the end. DeployOpen does not publish a price list, so compare quotes on scope and assumptions rather than totals.

How long does a CRM migration take?

No duration is fixed in advance because it depends on volume, data quality, the number of source systems and how quickly the business owners sign off. Ask a partner for a timeline tied to named milestones: discovery, mapping sign-off, each trial import, the cutover window and the post-migration review. Sales teams often need a freeze on new records during cutover, so agree on that window and on how changes made in the old system during the freeze will be captured. Treat any timeline without milestones and owner dates as an incomplete estimate.

How do we migrate from SuiteCRM 7 to SuiteCRM 8?

SuiteCRM documents the move from version 7 to version 8 as a migration, not an upgrade. A new SuiteCRM 8 environment is set up and the version 7 data is moved into it, after the version 7 instance is first brought to the latest 7.14.x or later release. Review customizations before you start, because the migration may remove non-core files under the public/legacy folder. Test the full path on a staging instance, confirm that custom fields, workflows and integrations were rebuilt, and confirm how users will log in, since SuiteCRM 8 supports LDAP and SAML. Ask any partner to show this path in their written scope.

What checks should run after a CRM migration goes live?

Post-migration checks should confirm record counts by object against the source, spot-check a sample of accounts, contacts and opportunities against the original records, and verify that owners, teams and sharing rules match the approved permission map. Check that attachments open, that activity history is linked to the right parent records, and that reports and dashboards return the same totals as before. Keep the source export read-only for an agreed period so the team can look up any missing detail. Record sign-off from each business owner so the migration has a clear end point.

How DeployOpen scopes and delivers a CRM migration

DeployOpen plans, implements and hands over self-hosted CRM migrations inside the client's own infrastructure, with the field mapping, duplicate rules, owner and permission mapping and post-migration checks written down before work starts. Engagements are fixed-scope, so the source systems, record volumes and target platform are agreed in writing first.

How we scope

Inventory source objects for accounts, contacts, opportunities, activities and attachments, including custom fields and stages
Agree the target platform, SuiteCRM or EspoCRM, and the hosting location in the written scope
Set out which record types, date ranges and attachment sizes move, and which stay archived in the source

How we build

Produce a field mapping workbook that names each source field, target field, transform and owner
Define duplicate matching rules and merge decisions with the client before any production import
Run trial imports on a staging instance and reconcile record counts, owners and permissions after each run

How we hand over

Deliver the mapping, import logs, reconciliation results and post-migration check results as documentation
Walk the client's administrators through owner, team and role mapping so the permission model can be maintained
Confirm backup and rollback steps for the production cutover, with each step recorded in the handover pack

How we support

Offer ongoing support, upgrades and testing as a retainer after handover, if the client wants it
Re-run reconciliation checks when the target platform receives a version upgrade or a SuiteCRM 7 to 8 move
Confirm with the client which support hours, response expectations and change process apply, as set in the contract

How to use this CRM data migration checklist

Which records, fields and relationships must move intact

The migration sequence from export to cutover

Freeze the source and export data

Inventory custom objects and fields

Build the field map

Set duplicate rules and matching keys

Run a trial import on staging

Reconcile counts and sample records

Map owners, teams and permissions

Load production and run post-migration checks

Cut over and retain the source archive