How to Export Data from Maximizer CRM: Methods & Limits

There is no single "Export Everything" button in Maximizer CRM. The built-in Import/Export/Transfer tool exports Address Book entries (companies and individuals) to CSV or tab-delimited files — and that is where its usefulness largely ends. Opportunities, cases, leads, and calendar data each require a different extraction path. Documents and attachments are stored as binary blobs in SQL Server and are not reliably exportable through any native UI function.

If your goal is a complete, migration-ready extract — to move to Salesforce, HubSpot, Zoho, or another modern CRM — you need to understand exactly what each method gives you, what it leaves behind, and where it breaks.

Migration-ready extract means source IDs, owner assignments, timestamps, user-defined field values, file attachments, and relationship keys all preserved in a format the target system can ingest. A flat CSV of contact names and emails does not qualify.

If you are still tempted to run a CRM move from spreadsheets alone, read Using CSVs for SaaS Data Migrations.

Which Method Should You Use?

The right extraction path depends on your deployment type, data volume, and what you need to preserve. Use this decision guide before choosing a method:

Quick Answer: How to Export Contacts via CSV

This is the path most Maximizer users try first. It works for a basic contact pull. It fails for anything migration-scale.

Step-by-step (Desktop Client)

1. Click the Maximizer button (multi-colored hexagon) at the top left of your screen. In older versions, select File. Navigate to Import/Export/Transfer → Address Book Entries.
2. Click Browse to choose a save location and file name. Set the format to Comma Separated Value (CSV).
3. Select the fields you want to export. Double-click each field or click Add to include it.
4. Click Export to generate the CSV file.

What this gives you

• Company and Individual Address Book entries
• Phone numbers, email addresses, physical addresses
• User-defined fields (UDFs) you explicitly select — but not table UDFs with multiple items, and not encrypted UDFs
• Notes (if selected — with delimiter risk)

What this does NOT give you

• Contacts (sub-entries under Companies) — CSV/tab export covers Companies and Individuals only. XML can include Contacts. (download.maximizer.com)
• Opportunities, leads, or cases
• Documents or file attachments
• Calendar entries or hotlist tasks
• Relational keys linking records to parent companies
• Interaction history

You must have the "Allow export" privilege to use the export commands. Some Maximizer versions (e.g., 10.5) only allow CSV export for companies, not contacts. You can export companies, contacts, and notes in XML format as an alternative. Check your version before assuming CSV covers everything.

The Core Methods to Extract Maximizer Data

Method 1: Native CSV / Tab / XML Export (Desktop Client)

Best for: Quick one-time Address Book pulls under a few thousand records.

CSV and tab-delimited formats export Companies and Individuals from the Address Book. They do not export Contact sub-entries, opportunities, cases, leads, documents, or interaction logs. Table UDFs with more than one item are unsupported in CSV/tab output, and encrypted UDFs cannot be exported via CSV, XML, or API — if your instance relies on encrypted UDFs, there is currently no documented export path for their values, and you should flag this to any migration team before starting. (download.maximizer.com)

XML/MXI export is the richer native option. According to Maximizer's admin guide, XML can optionally include Contacts, opportunities, Address Book UDFs, notes, documents, and Unicode output for non-English characters. It is still Address Book-centric, not a whole-instance dump. (download.maximizer.com)

A migration-critical caveat: unique IDs are exported for Companies and Individuals, but contact unique IDs are not exported in XML. That makes XML better than CSV for completeness but still problematic if your target system depends on stable contact-level identifiers. (download.maximizer.com)

UDF Export Compatibility by Method

User-defined fields behave differently across export methods. The table below summarizes what each method can and cannot handle:

Excel / Report Export (Web App)

The web client's Excel export pulls selected entries from the active page using the current column setup. Report templates are available for Address Book, Opportunities, Customer Service, Campaigns, and Hotlist. These exports are static snapshots — useful for auditing and user review, not for full-fidelity migration. (support.maximizer.com)

Calendar Sharing

Appointments use a separate path. Maximizer's Calendar Sharing feature publishes events in .ics format for Google Calendar, Outlook, and Apple Calendar. Useful for publishing schedules; not a migration tool for historical CRM activity. (support.maximizer.com)

Method 2: SQL Server .BAK Backup (On-Premise Only)

Best for: Full data extraction when you have direct server access.

On-premise Maximizer installations store data in Microsoft SQL Server. Each address book has its own database.

A .BAK backup is the most complete extraction path for on-prem users. Maximizer offers two backup modes: Regular Backup (requires the Address Book to be closed) and Quick Backup (can run against an open Address Book). Both create .BAK files containing the majority of Maximizer data, though custom dictionary and holiday files are excluded. (download.maximizer.com)

The key tables to know:

• AMGR_AbEntries — Address Book entries (companies, individuals, contacts)
• AMGR_Opportunity — Opportunities and deals
• AMGR_Notes — Notes attached to entries
• AMGR_Letters_Tbl — Documents and email attachments (binary encoded)
• AMGR_UDF — User-defined field values

Once the data is loaded, you can export tables using SQL queries in Management Studio to join views and tables and export the data to CSV.

For a migration-ready extract, you need JOIN queries that reconstruct parent-child relationships between companies and contacts, and between entries and their associated opportunities, notes, and documents. Here is a minimal skeleton that joins the three most critical tables:

SELECT
  ab.AbEntryKey,
  ab.CompanyName,
  ab.FirstName,
  ab.LastName,
  ab.Type,
  opp.OpportunityKey,
  opp.Description AS OpportunityName,
  opp.Revenue,
  n.NoteKey,
  n.NoteText,
  n.CreateDate
FROM AMGR_AbEntries ab
LEFT JOIN AMGR_Opportunity opp
  ON opp.AbEntryKey = ab.AbEntryKey
LEFT JOIN AMGR_Notes n
  ON n.AbEntryKey = ab.AbEntryKey
WHERE ab.Deleted = 0
ORDER BY ab.AbEntryKey;

This query is a starting point — your actual schema may include additional join conditions depending on your Maximizer version and any applied schema customizations. Verify column names in SQL Server Management Studio before running against production data.

Before starting any database-level extraction, audit your data and plan your field mapping. Our data migration checklist template covers the preparation steps most teams skip.

Method 3: Octopus API (Cloud & On-Premise)

Best for: Programmatic extraction of structured data including contacts, opportunities, leads, cases, notes, and tasks.

Octopus API (also known as Maximizer.Web.Data) is a web service API that provides access to Maximizer CRM data in JSON format. You can access your Maximizer CRM data from any web application, desktop application, or mobile app.

Authentication uses a Personal Access Token (PAT). To create one: navigate to My Profile → Personal Access Tokens in your Maximizer instance, generate a new token, and copy it immediately — it is not shown again. Include it in the Authorization: Bearer <token> header on every request. On-premise customers should use their domain URL as the endpoint, rather than api.maximizer.com.

The API exposes endpoints for Address Book entries, opportunities, leads, cases, notes, hotlist tasks, calendar appointments, interaction logs, and documents. This is the only method that gives you structured access to all major object types without direct database access.

Non-obvious constraint: reads are POST-based, not GET-based. Maximizer's Power BI integration guide calls this out explicitly. If your ETL tool assumes GET-only reads, expect custom work. (developer.maximizer.com)

Octopus API: Key Endpoints

The table below covers the primary endpoints used in a migration extraction. Maximizer's full API reference is at developer.maximizer.com.

All read operations use POST even when fetching data. Pass filter criteria and pagination parameters in the request body. (developer.maximizer.com)

A practical baseline extraction pattern:

# Baseline object export
POST /octopus/Read
 
# Persist stable source references
store: ID + Number   # not Key.Value
 
# Document binaries
GET /octopus/BinaryDownload/{document-key}

For any record you plan to reconcile later, store the invariant ID + Number pair, not the transient Key.Value. Maximizer's documentation states that Keys are not guaranteed to remain stable across sessions, servers, or versions, while ID and Number are the stable external reference pair. (developer.maximizer.com)

UDFs require special handling in the API. Complex table structures do not return as simple key-value pairs — you receive nested arrays of UDF definitions that must be mapped back to the core Address Book entry ID.

Ferret API v2 vs. Octopus API

Ferret API v2 is a read-only alternative to Octopus with a narrower object surface. Both are production-accessible, but they differ in meaningful ways:

Use Octopus if you need documents, full object coverage, or are building a complete migration pipeline. Use Ferret only if you need a lightweight read on a narrow object set and can tolerate its beta status. (developer.maximizer.com)

Octopus API Rate Limits & Webhook Constraints

Rate Throttling

The rate limits depend on which documentation you reference. The Microsoft Power Platform connector lists 100 API calls per connection per 60 seconds. (learn.microsoft.com)

Maximizer's own Ferret/Octopus developer documentation publishes edition-based limits that may be tighter:

(developer.maximizer.com)

If you have 50,000 Address Book entries and each requires a separate API call plus pagination, you are looking at 8+ hours of continuous extraction at the connector's maximum throughput — before accounting for retries, errors, or document fetches. At the Base edition's 30 requests/minute, it takes significantly longer.

Exceeding these ceilings triggers 429 Too Many Requests or 408 Request Timeout responses. When a 429 is returned, check the Retry-After response header — Maximizer's API sets this to indicate how many seconds to wait before retrying.

What a silent failure looks like: A naive extraction script without explicit backoff does not crash on 429 — it simply stops paginating. The API returns a successful 200 response for the last page it was able to serve before throttling, with no indication that further records exist. Your row count looks plausible, but records beyond the throttle cutoff are silently absent. The only reliable detection method is to compare extracted record counts against a pre-export total pulled from the Maximizer UI or a direct SQL count on AMGR_AbEntries.

Build exponential backoff into any extraction script, treating both 429 and 408 as retriable conditions with increasing wait intervals.

For a deeper look at why migration scripts cause silent data loss, see The Data Migration Risk Model: Why DIY AI Scripts Fail.

Webhook Constraints

Maximizer's webhook system pushes real-time notifications when records are created or updated. The hard constraints:

• 10 webhook targets per instance — if you need sync to multiple downstream systems, you run out of slots fast
• Organization-level only, admin-managed
• Targets must return 200 OK within 2 seconds — Maximizer retries twice, then permanently discards the event

(developer.maximizer.com)

Webhooks are designed for ongoing delta sync after a baseline export, not for historical backfill or bulk extraction.

Webhook Payload Structure

Maximizer webhook payloads are JSON objects. A typical notification for an Address Book update includes the event type, the affected record's key, and a timestamp. The payload does not contain the full record — it is a notification that a change occurred, not a snapshot of the record's state. Your listener must call the Octopus API (POST /octopus/Read) using the key in the payload to retrieve the current record data.

This means webhooks require a functioning Octopus API integration to be useful. A webhook alone tells you that something changed, not what changed.

The Attachment Problem: Why Native Exports Leave Files Behind

This is where most Maximizer migration projects stall.

Documents are stored in a blob object and you cannot export them. The native CSV, tab, and XML exporters extract text fields — document references, file names, metadata — but not the actual file contents.

In the Maximizer database, the AMGR_Letters_Tbl table stores documents and emails with attachments. The TextCol column in the letters table is of type image containing encoded data.

It is quite difficult to extract documents from Maximizer, and exporting emails with attachments is even more difficult. Specialized services provide a folder structure filled with documents and an accompanying Excel/tab file containing the data, filepath, and IDs for each document.

The storage model adds complexity. Maximizer documents can be embedded in the database as binary blobs, linked via UNC paths to files outside the database, or stored as hyperlinks to external locations. Each type requires a different extraction approach:

• Embedded blobs — must be extracted from AMGR_Letters_Tbl via SQL or the Octopus BinaryDownload endpoint. The TextCol column uses SQL Server's image data type. The internal encoding of the binary content inside TextCol is not publicly documented by Maximizer. Based on working with these blobs, the data is not plain base64 or a standard container format — it requires reading the raw bytes and identifying the file signature (magic bytes) to determine the original file type before writing it to disk. This is the hardest part of Maximizer document extraction and the step most DIY scripts skip.
• UNC-linked documents — the database stores the file path; the file itself lives on the server's file system or a network share. SQL gives you the path; you then need filesystem access to copy the actual file.
• Hyperlinks — the database stores only the URL or path reference. Whether the target file is accessible depends entirely on the external system it points to.

There is no documented file size limit for the BinaryDownload endpoint in Maximizer's public API documentation. In practice, very large attachments (multi-MB PDFs, video files, scanned image archives) increase extraction time significantly and are more likely to trigger the 408 Request Timeout condition. Plan for this when estimating extraction duration on instances with large document libraries.

In the Octopus API, a Document is a reference to a stored binary. The API provides a dedicated BinaryDownload endpoint for the actual file payload. Attachment migration is always at least a two-step job: export the document metadata records, then download the binaries — while respecting rate limits. (support.maximizer.com)

If your Maximizer instance contains Word documents, PDFs, email attachments, or scanned images attached to records, none of them will appear in your CSV export. You need either:

1. Direct SQL Server access to query AMGR_Letters_Tbl, read the raw binary from TextCol, identify the file type from its magic bytes, and write the files to disk
2. The Octopus API to iterate through entries and download binaries via the BinaryDownload endpoint
3. A migration specialist who has worked with Maximizer's internal binary encoding and can handle file-type identification and output structuring

Data Model Mismatches: Maximizer's Flat Structure vs. Relational CRMs

Maximizer's data model is Address Book-centric. Everything revolves around a central Address Book that holds companies, individuals, and contacts. Opportunities, notes, and cases link to Address Book entries, but the relationships are flatter than what Salesforce, HubSpot, or Dynamics 365 expect.

It is important to map the data model and fields from Maximizer to Salesforce at the start of the project as part of the design phase. Navirum's Maximizer-to-Salesforce guidance reinforces this: Maximizer's flat data model does not map directly to Salesforce objects, and some fields require entirely new objects in the target system. (navirum.com)

The core problem: Maximizer's flat CSV export does not include the keys that link contacts to their parent companies, or opportunities to their parent contacts. Without those relational keys, your Salesforce import creates orphaned contacts with no account association and orphaned opportunities with no pipeline context.

If you are using the API, build a crosswalk keyed on Maximizer's stable ID + Number pair, plus separate mapping tables for company-contact parentage, owners/users, opportunities, and document parents. Row counts alone are not enough to verify a successful migration. (developer.maximizer.com)

Does Maximizer Provide Official Migration Documentation?

Maximizer does not publish a comprehensive official migration guide for moving data out of the platform to a third-party CRM. The admin guide (download.maximizer.com) covers backup, restore, and the Import/Export/Transfer tool. The developer portal (developer.maximizer.com) documents the Octopus and Ferret APIs. Neither source addresses the end-to-end problem of exporting all object types with relational fidelity and attachments into a target CRM.

Third-party CRM vendors (Zoho, for example) publish their own Maximizer import instructions, but these typically assume you can deliver a clean CSV — which, as described above, is not achievable for a full migration without custom extraction work.

DIY vs. Migration Tools

Native Export + Manual Import

Cost: Free (your time excluded).

Works for: Small databases under 1,000 contacts with no attachments and no complex relationships.

Fails when: You need opportunities, documents, or notes with intact relational links. You will spend weeks in Excel running VLOOKUPs to stitch companies and contacts back together and manually uploading files one by one.

Zapier / Power Automate

Zapier lets you send info between Maximizer CRM and other apps automatically — no code required. Both platforms are useful for ongoing operational sync — triggering actions when a new lead is created, for example. They are not designed for bulk historical extraction. Running 20,000 contacts with 5 years of interaction history through Zapier one record at a time is neither practical nor cost-effective. The same rate-limit constraints apply through the Maximizer connector.

SuprSwitch (Maximizer → HubSpot)

SuprSwitch by Suprdense is a dedicated migration tool for moving data from Maximizer CRM to HubSpot, handling users, objects, associations, properties, and customizations. (suprdense.com) If HubSpot is your target and your data model is conventional, it can save significant time compared to DIY. Validate its handling of attachments, unsupported custom logic, and edge cases before committing — it is purpose-built for one target platform.

Migration Specialists

For complex migrations — especially those involving document extraction from binary blobs, custom field mapping across dozens of UDFs, and relational data reconstruction — a specialist team with direct Maximizer experience is the fastest path. This is especially true when the .BAK database contains encoded documents that require file-type identification from raw binary.

When evaluating a migration specialist for Maximizer data, ask:

• Have they extracted binary documents from AMGR_Letters_Tbl before? Can they show you a sample output structure?
• How do they handle the flat-to-relational transformation — specifically company-to-contact and entry-to-opportunity links?
• What is their approach to API rate limiting? Do they use adaptive backoff, and how do they detect silently dropped records?
• Do they run a delta sync so your team can keep working in Maximizer during the migration?
• How do they verify completeness — row counts only, or field-level and attachment validation?

For a broader comparison of migration approaches, see our guide to the Top 5 Best CRM Migration Solutions.

Pre-Export Checklist

Before you pull a single record out of Maximizer:

• Check your deployment type. On-prem (SQL Server access available) vs. cloud (API-only) changes your extraction options entirely.
• Inventory your data types. List every record type you need: Address Book entries, opportunities, leads, cases, notes, documents, calendar items, interaction logs, campaigns.
• Count records per type. This determines which extraction method is viable and how long API extraction will take at your edition's rate limit.
• Identify user-defined fields. Document every UDF name, type, and possible values. Table UDFs and encrypted UDFs have export restrictions in CSV/tab formats.
• Audit document storage. Determine whether your documents are embedded in the database, linked via UNC paths, or stored as hyperlinks. Plan a separate extraction workflow for each type.
• Map your target data model. Define how Maximizer's Address Book entries, opportunities, and cases map to your target CRM's objects before you start exporting.
• Test a small export first. Run the CSV or API export on a filtered subset of 50–100 records. Verify the output includes every field you need, in the format you expect — and validate at least one real document with its actual binary file.

For a complete preparation framework, use our data migration checklist template.

How ClonePartner Handles Maximizer Migrations

The Maximizer projects that go sideways usually look fine at first glance. The CSV opens. The backup restores. The API returns JSON. Then the real problems surface: linked files were never copied, custom fields lost context, contact-to-company relationships were rebuilt incorrectly, or the export script silently stopped at rate limits and nobody noticed.

We have done enough Maximizer extractions to know these failure modes. The three problems that trip up every DIY attempt:

1. Blob-encoded documents that no native export touches. We extract the actual files from AMGR_Letters_Tbl, identify file types from raw binary signatures, and deliver them as a structured folder hierarchy with a lookup index. For API-based extractions, we handle the BinaryDownload endpoint with built-in rate limiting.
2. The API throttle ceiling. Our extraction scripts include adaptive backoff so we pull every record without hitting 429 errors or silently dropping data.
3. The flat-to-relational transformation. We preserve Maximizer's internal identifiers and use them to rebuild parent-child relationships (Company → Contact, Entry → Opportunity, Entry → Note) in the target CRM.

We use a delta-sync approach so your team keeps working in Maximizer while we migrate historical data, capturing final changes right before go-live. We handle Maximizer → Salesforce, Maximizer → HubSpot, Maximizer → Zoho, and custom targets.