How to export your data from SugarCRM

How to export your data from SugarCRM before the contract ends

Data can leave SugarCloud through documented paths, but not every object or attachment arrives in one file. If a renewal, a price change, a data residency requirement or a plan to leave has set your deadline, start by inventorying what your teams hold in Sugar. Sort it into three groups: what you can pull yourself, such as record-level exports where your edition and role allow them, what needs a request to Sugar, such as full backups and some uploads, and what may not come out at all, such as system configuration and workflow logic. Confirm each group against your edition and contract before the notice period starts. The rest of this page covers each path, the order to run them in and how to verify what you received.

Run the requests in an order that leaves time to check the results. Ask Sugar Support early for a full backup, and get the package contents confirmed in writing, including whether attachments, email, documents and custom module data are included. Then pull record-level exports for anything the backup does not carry in a usable form. Verification is where most gaps appear. Compare record counts per module against the live instance on the same date, open a sample of attachments, and check that related records still link to their parents. Keep a dated log of each file, its source and who approved it, since you will need that record if a figure is later disputed.

Before the contract ends, get three things in writing: the format and scope of the final package, the date your access to the instance stops, and how long Sugar retains your data after termination and how it is deleted. Ask whether copies stay in the region you contracted, because a residency requirement applies to data held after exit too. Then restore the package into a staging environment, such as a SuiteCRM test instance if that is your target, and confirm that a user can find a closed deal, its attachments and its history. If the restore fails, raise it with Sugar now, while your support relationship is still active.

Which SugarCRM data you can export and by which path

This table maps the data types a Sugar Sell or Sugar Enterprise customer usually holds to the export paths available: a backup requested through Sugar Support, an upload request, a download from SugarCloud Insights, or the backups API. The documentation available for this page does not state file formats, scope limits or turnaround times, so those cells tell you what to confirm. Treat each row as a question list for Sugar Support before the export starts.

Data type	Likely export path	Format and scope	What to confirm in writing
Modules and records	Full backup requested through Sugar Support, or download from SugarCloud Insights	Confirm whether the backup is a full database copy	Which modules, record counts and date ranges the package includes
Custom fields and layouts	Backup or backups API, if the instance is on SugarCloud	Confirm whether field definitions are exported as metadata	Whether custom field types and dropdown lists export with their values
Relationships	Full backup requested through Sugar Support	Confirm whether relationship tables are included in the database copy	How many-to-many links between modules are represented in the package
Attachments and documents	Upload request to Sugar Support, if files are not in the standard backup	Confirm whether files come as a separate archive	Whether file storage paths and file sizes are preserved and checked
Users, teams and roles	Full backup requested through Sugar Support	Confirm whether password hashes are included	Whether role assignments and team membership export together with records
Audit history	Full backup requested through Sugar Support, if audit tables are enabled	Confirm whether audit tables are part of the backup	How long audit history is retained and whether it is part of the package
Configuration and workflows	Upload request or Sugar Support handover, since settings may not be in the database copy	Confirm whether settings, workflows and email templates export	Which Sugar-only features need documenting, since they may not transfer

What does not come out of a SugarCloud export, and how to cover the gap

A database backup or record export captures the core CRM data, but several categories sit outside it or only partly inside it. Each card below names one of those gaps, the documented workaround you can run yourself, and the question to put to Sugar Support before the contract ends.

Attachments and documents

Files attached to records and documents stored in the file system are often not part of a database dump, so the database can restore records that point to files you do not have. Before the contract ends, copy the file store separately, confirm its path with Sugar Support, and check that file counts in the package match what the records reference. Ask Sugar Support whether the backup includes the upload directory or only the database.

Integration data

Data synced from connected third-party tools typically lives in the connector's own store, not in the CRM tables you export. Write down every integration, its source system, and the fields it writes, then export those source records from the originating tool. Ask Sugar Support which integration tables, if any, are included in a full backup.

Email and calendar sync

Email threads and calendar events synced through Sugar's mail and calendar connectors may be stored in a form that a record export does not show. Use the mail provider's own archive or export tool for the mailboxes involved, and record which users had sync enabled. Ask Sugar Support what share of email and calendar content is retained in a backup.

Workflow and process definitions

Workflows, alerts and process logic are configuration, not records, so a data export leaves them behind. Capture each one as a screenshot of its trigger, conditions and actions, and keep a written inventory with its owner and purpose. This inventory is also the input you need for rebuilding the logic in the target CRM.

Reports and dashboards

Report definitions and dashboard layouts usually do not travel with record data. Export the results of each report you rely on to a file so the figures are preserved, and document the filters, groupings and date ranges behind them. Ask Sugar Support whether report definitions are included in the backup package or must be recreated.

Predictive and AI outputs

Scores, forecasts and recommendations produced by Sugar's predictive or AI features are generated from the data and the vendor's models, so they are not a stored history you can simply export. Keep a record of the scoring fields that were visible to users and the date each was produced. Ask Sugar Support whether any generated scores are stored in the database or only computed on request.

The sequence for a complete SugarCRM export

This sequence produces a verified, stored copy of your Sugar data and attachments, with a record of what was requested, what was received and what was confirmed. Each step closes with a check, so you know whether the package is usable before the contract ends.

Inventory the instance and its customizations
Your Sugar administrator, with a business owner for each module, lists every module in use, custom fields, relationships, workflows, email templates, integrations, scheduled jobs and user accounts. Record the record count per module from the live instance and note whether the instance is SugarCloud or on-site, since that affects who can run the backup. The output is a dated inventory document. Check that every module has a count and an owner. Any item without either is flagged before you go further.
Confirm the contract end date and notice terms
Your contract owner reads the order form and master agreement to confirm the end date, the notice period for non-renewal, and the terms for returning or deleting customer data after termination. Ask Sugar in writing to confirm any point that is unclear, including how long the vendor keeps data after the end date. The output is a written note with those dates and terms. Check that the notice deadline is on your calendar and that the data return terms are confirmed in writing, not only assumed.
Request the full backup and uploads in writing
Send a written request to Sugar Support that names the instance, the environment and the content you need, including the database, file attachments and any documents stored in Sugar. Ask what the package contains, which file formats it uses, whether it includes a manifest, and how long the download stays available. Keep the ticket number. The output is a support ticket with a confirmed scope. Check that Sugar's reply lists what the package contains. If the reply is a summary without a file list, ask again in the same ticket before accepting it.
Download the package through Insights or the backups API
Once Sugar makes the package available, download it through SugarCloud Insights or the backups API, depending on what your edition and access rights allow. Confirm with Sugar Support which method applies and whether the API needs a dedicated service account. Save the files to a controlled staging location and calculate a checksum for each file as soon as the download completes. Check that the file sizes match what Sugar reports and that the archive opens without errors. If a download fails or a file is incomplete, retry from the same request and log the attempt.
Store the package with checksums and access controls
Move the verified package to encrypted storage that only named staff can reach, and record each file's checksum in a register alongside the date, the person who downloaded it and the source ticket. Turn on access logging so later reads are traceable. The output is a storage record that a reviewer can follow from the ticket to the stored file. Check that a fresh checksum from the stored copy matches the value in the register. If it does not, discard that copy, download again and do not use the mismatched file.
Restore the package to a separate environment
Restore the package into a non-production environment, such as a SuiteCRM 8 or EspoCRM test instance, and leave the live Sugar instance unchanged. Keep an untouched copy of the original package for audit. Document each restore step, the software versions used and any errors. The output is a working test instance loaded with your data. Check that the database imports without errors, that the application starts, that a test user can sign in and that you can open a sample of records and their attachments.
Reconcile record counts and attachments
Compare the record count for each module in the restored environment with the counts you recorded in the inventory. Sample records to check that field values and relationships came through, and compare the attachment count and file checksums with the package manifest. Save the reconciliation report with its date and reviewer. Check that every count matches. If a module or attachment set differs, rerun that part of the export, check the mapping, and ask Sugar Support in writing whether the differing content was in the package. Sign off only when all counts match or each difference is explained in writing.

Which export path fits your team and your timeline

Choose this path when the contract is ending or a renewal decision is pending and you need a complete copy of the instance before access stops. The full package is requested through Sugar Support, so the scope, format and delivery terms need to be confirmed in writing before the request is made, not after the package arrives.

Contract owner approves the request: The person who holds the renewal decision should sign off on the request in writing, because the deadline that matters is the end of access, not the date the team starts planning.
Confirm scope with Sugar Support: Ask whether the backup covers the database, uploaded files, custom code and configuration, and whether your deployment is SugarCloud or on-site, since the answer changes what you receive.
Confirm delivery and availability: Ask how the package reaches you, in what format, how long the download link stays active and whether a second copy can be requested later.
Your team verifies the package: Restore it on a separate machine, compare record counts per module and open a sample of attachments to confirm they are readable.
Store the copy under your controls: Keep it in encrypted storage you manage, with access logs and a retention period set by your compliance team.

Before the contract ends, confirm in writing what the package contains, then test a restore, because a file that downloads has not yet been shown to open.

What to verify in the package before you accept it

Do not accept a Sugar export until it has been restored and reconciled in a separate environment. A package that opens as files proves little. Ask for a restore into a clean SuiteCRM or staging instance, and confirm the database loads and the application starts without manual repair. Then compare record and attachment counts module by module against the live Sugar instance, including accounts, contacts, leads, opportunities, cases, notes and documents. Record any gap, and get Sugar to explain it in writing before you move on.

Next, check the structure, not just the volume. Confirm that custom fields and custom modules appear with their types and values, that relationships between records resolve, and that user and team assignments still point at the right owners. Orphaned records, blank owner fields or user IDs that match no account are the usual signs of an incomplete export. Confirm the file set against what Sugar delivered: compare file names, sizes and checksums (for example, SHA-256 values published alongside the archive) and keep a copy of that manifest with the package. If Sugar does not supply checksums, ask for them or generate your own at the moment of receipt.

A restored copy is still a copy until a named person signs off the reconciliation. Assign one owner from the business and one from IT, record the counts and exceptions in a sign-off note, and do not treat the migration as complete until both have approved it. Retention of the Sugar package is a separate decision. Decide how long the archive is kept, where it is stored, who can access it and when it is destroyed, and make that decision with your legal and compliance teams, because the rules for retaining customer data are not the same as the rules for proving a migration worked.

What to plan before the SugarCRM contract ends

Most of the risk in leaving SugarCRM sits in the weeks before the subscription stops. The decisions below set the dates, people and data scope you need before you make the final request. Confirm every date, window and term in your signed agreement, since that document governs what you can request and when.

Confirm the notice and stop dates

Confirm the notice period and the date the subscription ends in your signed agreement. Work backward from that date to set the last day you can request a backup, a final export and a test restore. Record who gave notice, in what form, and whether the agreement renews automatically. A missed notice window can extend billing, so treat it as a dated item on the project plan.

Know the support access window

Ask Sugar in writing how long Support will accept backup and export requests after the subscription stops. Also confirm whether your administrators, users and API credentials keep working during that period. Requests may take time to fulfill, so the confirmed window determines how many export and restore rounds you can afford. Write the end date into the project plan and the cutover runbook.

Use the export as migration input

Whether you move to SuiteCRM 8 or EspoCRM, the package becomes the starting dataset for mapping modules, fields and relationships. SuiteCRM's pre-migration guidance calls for a staging instance, file and database backups and a review of customizations first. Decide which records, fields and history belong in the target before you request the final package, so you are not reconciling scope under deadline.

Staff the restore and reconciliation

A restore into staging needs an administrator for the target platform, someone who understands the Sugar data model, and a business owner for each module who signs off record counts and sample records. Agree these roles, and how much of their time they will give, before the contract ends. If staffing is decided late, reconciliation gets squeezed into the last days of access, when a missing file or field is hardest to chase with Sugar Support.

Scope attachments and integration data

Confirm in writing whether the backup includes record attachments and documents, and whether it includes data from connected email, calendar and other integration tools. If either is excluded or delivered separately, plan a separate request or an alternative source. List every connected system now and decide whether each one is rebuilt, replaced or retired on the new platform, so nothing is left unmapped at cutover.

Set retention and access controls

Decide how long the export is kept, where it is stored, who can open it and when it is deleted. Encrypt the archive at rest, limit access to named roles, and log every download. Your retention period should follow your organization's legal, contractual and records policies, which your compliance lead should confirm. Record a checksum of the package so you can later show that the copy you restored matches the copy you received.

Questions buyers ask before exporting SugarCRM data

What does it cost to export data from SugarCRM?

The vendor charge depends on your agreement with Sugar, so the first step is to confirm in writing which export deliverables are included and which carry a fee. Your internal costs are separate and recur with each export: staff time to request the backup, download it, verify it and document the result, plus a non-production environment where the data can be restored and tested. Costs rise when you need several exports, such as a trial load followed by a final cutover, or when attachments and custom modules add volume to check. Ask for a quote that lists each deliverable, who performs it and what it costs once versus on each repeat. If you engage DeployOpen, the work is agreed as a fixed scope with written deliverables before it starts, so the quote follows from the items you define.

How long does a SugarCRM data export take?

The timeline is set by Sugar's response to your request, the size of the database and file store, and how much checking your team needs before accepting the package. Sugar's own turnaround for a backup or upload should be confirmed in writing, since no supplied figure applies to every contract. Plan separately for the parts you control: downloading large files, restoring the package into a test instance, reconciling record counts and reviewing custom fields. Export work also gets longer when the export must be repeated after a failed check. Build a schedule with a buffer before your Sugar contract end date, and ask Sugar Support which date their export window closes, so the deadline is not discovered late.

What do administrators and data owners need to provide?

Administrators must provide access and authority: a named contact who can open Sugar Support requests, access to the Sugar admin console or SugarCloud Insights where downloads are offered, and credentials for any database or file store used on-site. Data owners, usually sales operations, finance and customer service leads, must confirm which modules, fields and historical records must survive the move and which can be retired. They also need to agree how records with personal data will be handled and retained. Document these decisions in a sign-off sheet before the export starts, because later changes to scope usually mean repeating part of the work.

Can an internal team export SugarCRM data without outside help?

A capable internal team can usually manage the request, download and storage steps, provided it knows which deliverables Sugar will produce and how to verify them. The harder work is the checking: confirming record counts by module, testing attachments, reviewing custom fields and relationships, and confirming that a restored copy opens and behaves as expected. Those tasks need database and application skills and time that competes with daily operations. Decide early whether one or two people will own the export end to end, and whether they have a staging environment to restore into. If those conditions cannot be met, a partner can run part or all of the work under a written scope, with your team keeping control of the decisions.

What should we ask Sugar Support in writing?

Ask for every commitment in writing, with a named contact and a reference number for each request. Confirm what a full backup contains, whether it includes file uploads and attachments, and whether those uploads must be requested separately. Ask in which formats the data is delivered, how the download is made available, how long the link or file stays accessible, and whether a backup can be taken again before the contract ends. Ask whether any fees apply to each deliverable, what the response window is for each request, and what Sugar will do if a package fails validation. Get the answers on the record before you plan the cutover, since they determine the work your team must do.

What should we check in the package before the contract ends?

Verify the package before the contract end date, not after, because a missing file cannot be recovered once access ends. Check record counts for each module against the live system, confirm that attachments open and link to the correct records, and review custom modules, fields, dropdown values and relationships. Confirm that user records, roles and historical activity are present where you need them, and note what the package leaves out, such as system configuration, workflows or integrations. Record the checks in a dated report signed by the data owner. The SuiteCRM migration guidance lists the same preparation steps, including a full backup and testing on staging, which apply to any destination.

When should we bring in an implementation partner for the export?

Bring in a partner when the export is tied to a platform change, when the data model is heavily customized, or when the internal team lacks time or database skills to verify the package. A partner is also useful when the export has a compliance dimension, such as evidence that personal data was handled and retained under your own rules. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and it works from a written, fixed scope with deliverables and timelines agreed before work begins. A partner does not replace Sugar's obligations under your contract, so confirm those obligations in writing first. Ongoing support after the move is available as a retainer.

How DeployOpen scopes and delivers a SugarCRM data exit

DeployOpen approaches a SugarCRM data exit as a fixed-scope engagement with written deliverables. We start from what SugarCloud can actually produce, verify the package against your data model, and hand over a dataset your team can load and check without depending on Sugar.

How we scope

The written scope lists which Sugar modules, custom fields, attachments and relationships must be present in the exported package.
We confirm with you which backup or export requests have been raised through Sugar Support and which items still need to be requested.
The scope names the target platform, such as SuiteCRM or EspoCRM, and the record counts you need to reconcile after the move.

How we build

We build an extraction and checking procedure against a copy of your data, so the live Sugar instance is not changed during the exit.
Each export is compared with source record counts, field values and file attachments, and gaps are logged with their cause.
Scripts and transformation rules are version-controlled and rerun on the final export so the result is repeatable.

How we hand over

Deliverables include the verified export package, a field-level mapping document and a reconciliation report signed off by your data owner.
We document where each export came from, when it was taken and which Sugar features had no equivalent in the target system.
The handover includes a checklist of items to verify before the SugarCloud contract ends, so nothing is lost after access closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover.
Retainers can cover a repeat export before final cutover, if your team needs to refresh the package during testing.
Support scope and response arrangements are agreed in writing, and DeployOpen does not publish a price list, so a quote follows from the written scope.

How to export your data from SugarCRM