CRM migration

Migrate from Assembly Trialworks to Salesforce Sales Cloud

Field-level mapping, validation, and rollback between Assembly Trialworks and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.

Assembly Trialworks logo

Assembly Trialworks

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

100%

12 of 12

objects map 1:1 between Assembly Trialworks and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

5–10 business days

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Assembly Trialworks stores data as plaintiff law firm cases: clients as parties, injuries, medical records, statutes of limitations, and case documents in a file-tab structure. Salesforce Sales Cloud has no native legal case object in its standard Sales Cloud edition — cases live in Service Cloud or as custom objects. The migration carries everything Trialworks stores natively (client records, case details, medical record references, statute dates, document attachments, custom fields) into Salesforce's Account-Contact-Case-Opportunity model. The harder problems are mapping Trialworks party types to Salesforce Contacts, preserving the multi-tab case file structure across a custom Case object, handling statute-of-limitations date logic, and re-uploading document attachments to Salesforce Files or a linked DMS. We sequence the migration so foreign keys resolve correctly: Accounts first, then Contacts, then Cases with parent Account and Contact lookups, then custom objects for medical records and injuries. A delta-pickup window captures any Trialworks records modified during cutover. We use Salesforce Bulk API 2.0 for efficient record loading with batch-level error handling. All automations, workflows, and templates in Trialworks do not migrate — we export those definitions as rebuild references for your Salesforce admin.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Assembly Trialworks logo

Assembly Trialworks

What's pushing teams away

  • Assembly Software is actively steering Trialworks customers toward Neos, its cloud-only successor, and has stopped creating or modifying custom dashboards, making the platform feel like it is entering long-term maintenance mode.
  • Neos is cloud-only with no on-premise option, which forces firms that require local server deployment to either switch platforms entirely or accept a deployment model they never chose.
  • Users report that Neos lacks features Trialworks had, and G2 satisfaction scores for Neos exceed Trialworks, creating pressure without clear functional parity at launch.
  • The forced transition conversation is creating churn anxiety among firms that do not want to migrate to a cloud product but face uncertainty about Trialworks' long-term roadmap despite Assembly's official no-EOL statement.
  • Windows-only workstation requirement and lack of native Mac or mobile support increasingly conflicts with modern law firm BYOD expectations and hybrid work arrangements.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How Assembly Trialworks objects map to Salesforce Sales Cloud

Each row shows how a Assembly Trialworks object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Assembly Trialworks

Party (Client/Plaintiff)

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

Trialworks party records with role type 'Plaintiff' or 'Client' map directly to Salesforce Contacts. Each party record's name, address, phone, and email fields translate to Contact standard fields. The Contact's AccountId lookup points to the primary defendant Account or a default 'Matter' Account structure your firm defines before migration.

Assembly Trialworks

Party (Defendant / Medical Provider / Witness)

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

Non-client party records (Defendant, Medical Provider, Insurance Adjuster, Witness) map to Salesforce Contacts with a custom Party_Role__c picklist field to preserve the Trialworks role type designation. Multiple contacts can share the same Case parent. The original role value is captured in the custom field for reporting and rebuild reference.

Assembly Trialworks

Case / Matter

maps to

Salesforce Sales Cloud

Case (custom object) or Opportunity

1:1
Fully supported

Trialworks case files map to a Salesforce custom Matter__c object or to the standard Case object if your org includes Service Cloud. We recommend a custom object because it supports the multi-tab structure Trialworks uses. Each tab (Parties, Medical Records, Injuries, Statutes) becomes a related list or a child custom object with a lookup to Matter__c.

Assembly Trialworks

Medical Record Reference

maps to

Salesforce Sales Cloud

Custom: Medical_Record__c

1:1
Fully supported

Trialworks medical record entries (provider name, date of service, record type, chart reference) have no Salesforce standard equivalent. We create a Medical_Record__c custom object with a lookup to the Matter__c parent and map each field individually. If records include attached files, those are re-uploaded to Salesforce Files and linked via ContentDocumentLink.

Assembly Trialworks

Injury / Damages Record

maps to

Salesforce Sales Cloud

Custom: Injury__c

1:1
Fully supported

Injury descriptions, body parts affected, and damage categories from Trialworks tab fields map to a custom Injury__c object linked to Matter__c. Each injury gets its own record so your Salesforce reports can filter by injury type or body part. Injury severity and ICD code references map to custom picklist or text fields.

Assembly Trialworks

Statute of Limitations Date

maps to

Salesforce Sales Cloud

Custom: Statute_of_Limitations__c (field on Matter__c)

1:1
Fully supported

Trialworks statute-of-limitations dates map to a Statute_of_Limitations__c date field on the Matter__c object. A companion Statute_Alert_Date__c field (calculated as 90 or 180 days before the deadline) enables Salesforce Flow alerts. Firms can extend this with a Formula field that displays days remaining as a traffic-light indicator.

Assembly Trialworks

Case Document / Attachment

maps to

Salesforce Sales Cloud

Salesforce Files (ContentDocument / ContentVersion)

1:1
Fully supported

Trialworks file attachments are downloaded from the case file tabs (PLEADINGS, DISCOVERY, MEDICAL, CORRESPONDENCE) and re-uploaded as Salesforce Files. Each file is linked to the Matter__c record via ContentDocumentLink. Original file names, categories, and upload dates are preserved in Salesforce File metadata. Large document sets may require chunked upload batches.

Assembly Trialworks

Insurance / Coverage Information

maps to

Salesforce Sales Cloud

Custom: Insurance_Coverage__c

1:1
Fully supported

Insurance carrier, policy number, coverage limits, and deductible information from Trialworks maps to a custom Insurance_Coverage__c object linked to Matter__c. Policy type (auto, GL, workers' comp) maps via value_mapping to a custom picklist. Coverage amounts map to currency fields with the original currency preserved.

Assembly Trialworks

Firm User / Staff

maps to

Salesforce Sales Cloud

User

1:1
Fully supported

Trialworks user accounts are matched to Salesforce Users by email address. Active Trialworks users with a confirmed Salesforce User match get their cases assigned to their Salesforce UserId as OwnerId. Unmatched users are flagged before migration — your admin either creates Salesforce User accounts first or assigns those records to a fallback owner.

Assembly Trialworks

Calendar / Deadline Entry

maps to

Salesforce Sales Cloud

Event / Task

1:1
Fully supported

Trialworks calendar entries and court deadline reminders map to Salesforce Events (for scheduled hearings or depositions) or Tasks (for to-do items). The original event date, time, and description map to Event.StartDateTime and Subject fields. Court deadlines that require all-day reminders map to Salesforce Tasks with IsAllDayEvent=true and a custom Due_Date__c datetime field.

Assembly Trialworks

Custom Field (per-firm)

maps to

Salesforce Sales Cloud

Custom field on destination object (__c)

1:1
Fully supported

Every Trialworks custom field maps to a Salesforce custom field on the appropriate destination object. Field type mapping follows standard conventions: text fields to Text(255), long text to Long Text Area, dates to Date, pick-lists to picklist with values preserved. Salesforce __c suffix is applied to all custom field API names. Fields are created in the target org before the migration run.

Assembly Trialworks

Billing / Fee Arrangement

maps to

Salesforce Sales Cloud

Custom: Fee_Arrangement__c

1:1
Fully supported

Contingency fee percentages, hourly rates, flat fees, and retainer amounts from Trialworks map to a Fee_Arrangement__c custom object or fields on Matter__c. Fee type maps via value_mapping to a structured picklist (Contingency, Hourly, Flat Fee, Hybrid). Outstanding balance tracking is not native to Salesforce and requires a custom field or integration with a billing tool.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Assembly Trialworks logo

Assembly Trialworks gotchas

High

No public API means migration requires direct SQL database access

High

Assembly has discontinued custom dashboard creation and modification

Medium

FileIT document import requires a parallel folder-to-case mapping step

Medium

Custom fields are firm-specific and must be discovered before mapping

Medium

Firms being pushed toward cloud-only Neos despite needing on-premise

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Trialworks case file tabs do not map to a single Salesforce object — they fragment across a custom object graph

    Trialworks organizes case data in a tabbed file structure: Parties, Medical Records, Injuries, Insurance, Documents, Statutes. Salesforce has no native equivalent — the tabs fragment across Matter__c (parent), Medical_Record__c, Injury__c, Insurance_Coverage__c (all child objects), and Salesforce Files. The fragmentation means that reporting across all case dimensions requires custom report types or a joined report in Salesforce. We generate a custom report type definition as part of the migration handoff so your admin can build cross-object reports on day one. If your firm uses the FileIT import structure, document categories (PLEADINGS, DISCOVERY, MEDICAL) map to Salesforce File ContentDocument.Category or custom metadata for classification.

  • Statute of limitations date logic is not native to Salesforce — deadline tracking requires Flow or Apex

    Trialworks tracks statute of limitations dates with deadline alerts. Salesforce has no native statute-of-limitations field. We map the raw SOL date to a Statute_of_Limitations__c custom date field on Matter__c, but the alert logic (e.g., 'remind 90 days before SOL') requires a Salesforce Flow or Apex trigger that runs a scheduled check against today(). We include a baseline Flow definition in the migration handoff that creates a Task reminder 90 days before the SOL date. Firms with more complex deadline logic (e.g., tolling events, jurisdictional variations) need their admin to extend the Flow or engage a Salesforce developer.

  • Document re-upload is required — Trialworks file storage is not directly accessible from Salesforce

    Trialworks stores case documents in a proprietary file structure on the firm's server or in Trialworks Cloud. Salesforce Files store documents in Salesforce's ContentVersion object, which is separate from Trialworks storage. All case documents must be downloaded from Trialworks (via FileIT export or direct file share) and re-uploaded to Salesforce. Large firms with thousands of documents per case require chunked upload batches with ContentVersion API calls. We handle the download, category mapping, and re-upload. The original document metadata (upload date, author, category) is preserved in Salesforce File description fields. If your firm uses an external DMS (SharePoint, iManage, NetDocuments), you may choose to link documents via Salesforce Files external storage instead of migrating them into Salesforce.

  • Trialworks workflows and case automations do not migrate — case-specific logic must be rebuilt in Flow

    Trialworks case automations (e.g., status-change triggers, deadline creation rules, document-category workflows) are platform-native and do not export in a Salesforce-compatible format. Salesforce Flow is the replacement tool for case-based automation. We export your Trialworks automation definitions as a rebuild reference document that lists each rule's trigger, condition, and action. Your Salesforce admin or a consultant uses this document to build equivalent Flows. The export does not include logic built in VBA macros or external integrations connected to Trialworks via ODBC — those require separate assessment.

  • Party-to-contact deduplication across multiple cases requires pre-migration cleanup

    Trialworks allows the same individual to appear as a party in multiple cases (e.g., a medical provider appearing across many plaintiff cases). Salesforce Contacts deduplicate by email by default. If the same medical provider appears across 50 cases with the same email, Salesforce will either create one Contact (if email is identical) or 50 duplicates (if emails vary slightly). We recommend creating an Account for the medical provider and using Account Contact Relationships for cross-case visibility rather than duplicating Contact records. We surface all multi-case party records in a pre-migration report so your team can decide on a consolidation strategy before the migration run.

Migration approach

Six steps for a successful Assembly Trialworks to Salesforce Sales Cloud data migration

  1. Stand up Salesforce schema first

    Before data moves, we create the custom objects (Matter__c, Medical_Record__c, Injury__c, Insurance_Coverage__c), custom fields (__c suffix), and custom picklists your migration needs. We deliver a schema setup plan based on your Trialworks configuration — the number of custom fields per object, the number of case tabs, and the document categories in use. Your Salesforce admin reviews and creates the schema in your sandbox before we run validation. This step runs in parallel with data extraction planning from Trialworks.

  2. Extract Trialworks data and resolve party contacts

    We extract all records from Trialworks via file export or API access: parties, cases, medical records, injuries, insurance coverage, calendar entries, and document file lists. Parties are deduplicated across cases using email matching and a firm-defined primary-contact rule. Document files are downloaded in structured batches preserving the case-folder hierarchy. Unmatched attorney users (for OwnerId resolution) are flagged so your admin can create Salesforce User accounts or assign a fallback owner before migration.

  3. Run sample migration with field-level diff

    A representative slice migrates first — typically 100–500 records spanning cases, parties, medical records, and document attachments. We generate a field-level diff between the Trialworks export and the Salesforce target so you can verify that statute-of-limitations dates landed correctly, party roles mapped to the right picklist values, and document categories preserved the Trialworks folder structure. This step identifies any missing picklist values, required field gaps, or mapping errors before the full run commits.

  4. Cut over with delta-pickup for in-flight records

    Full migration runs against Salesforce using Bulk API 2.0 for efficient batch loading. A delta-pickup window (typically 24–48 hours) captures any Trialworks records created or modified during the cutover — for example, new parties added by staff who were working in Trialworks while the migration ran. Audit log captures every operation. One-click rollback is available if reconciliation fails or record counts do not match expectations. After rollback confirmation, the delta records are merged in a follow-on run.

  5. Deliver migration handoff package

    After successful cutover, we deliver a migration handoff package containing: the full field mapping spreadsheet, Salesforce Flow definitions for statute-of-limitations alerts and case status change reminders, a custom report type definition for cross-object case reporting, a Trialworks automation export (PDF) for your admin to rebuild in Flow, and a post-migration data quality report showing record counts, duplicate counts, and any records that landed with warnings. We schedule a 30-day post-migration support window for any data corrections.

Platform deep dives

Context on both ends of the pair

Assembly Trialworks logo

Assembly Trialworks

Source

Strengths

  • Windows-native platform with deep Microsoft Office and WordPerfect document generation integration that litigation attorneys know well.
  • SQL Server backend gives IT staff full access to the database for custom reporting, backup, and integration work.
  • Customizable dashboards let individual users surface case metrics and pipeline views tailored to their practice area.
  • Supports on-premise, hosted, and virtual desktop deployment, giving firms flexibility in how they run the software.
  • Structured Claims and Parties data model aligns closely with how PI and liability litigation firms actually organize case information.

Weaknesses

  • No public REST API documented, making programmatic export and import a custom SQL-level operation rather than a standard integration.
  • Assembly has stopped creating or modifying custom dashboards, signaling reduced investment in the platform's feature set.
  • Strictly Windows-only workstations; no native Mac or Linux client, limiting deployment flexibility for modern hybrid work environments.
  • Cloud-only successor (Neos) has no on-premise option, forcing firms with local server requirements to migrate to a different platform entirely if they want to stay current.
  • Support for NeosAI and newer AI-powered features is concentrated in Neos, leaving Trialworks users without access to Assembly's most recent product investments.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Assembly Trialworks and Salesforce Sales Cloud.

  • Object compatibility

    B

    2 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Assembly Trialworks: Not applicable—no public API.

  • Data volume sensitivity

    B

    Assembly Trialworks doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Assembly Trialworks to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Assembly Trialworks to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during Assembly Trialworks to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Assembly Trialworks to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most Trialworks-to-Salesforce migrations complete in 5–10 business days for under 25,000 records. Firms with 100,000+ records, extensive document attachment libraries, or 30+ custom fields per object extend to 3–6 weeks. The longest planning step is schema setup — creating the Matter__c object, custom fields, and pick-lists in Salesforce before data can load. We run a sample migration with field-level diff in the first 1–2 days so you can verify mapping quality before the full run commits.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Assembly Trialworks.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day