Migrate from Striven to Salesforce Sales Cloud

Striven Customers map directly to Salesforce Account. The Type field on Account is set to Customer. Address, phone, and contact detail fields migrate 1:1. The Account record must be created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert. Customers with an active Customer Portal in Striven are flagged in a custom field striven_portal_active__c for the customer's admin to configure Salesforce Experience Cloud portals post-migration.

Striven Vendors map to Salesforce Account with Type set to Vendor. This means the same Account object holds both Striven Customer and Vendor roles, and an Account can have both roles if the entity is both a customer and a supplier. We use the Striven vendor ID as an external lookup key and set a custom Type field to preserve the original entity classification.

Striven Employees are required prerequisites for accounting migration but have no native Salesforce equivalent. We migrate them as Contact records attached to a designated internal Account (e.g., 'Company Internal') that we create at the start of migration. Role, department, and employment status migrate to custom Contact fields. Active Employees get a matched Salesforce User record during user provisioning; inactive employees remain as Contacts only.

Striven Items (products and services) map to Salesforce Product2 records. The Striven item type (Inventory, Non-Inventory, Service) is preserved in a custom field item_type__c. Standard Pricebook entries are created during import. The Striven SKU maps to ProductCode. Items must be in Salesforce before Sales Orders or Purchase Orders can be created because OpportunityLineItem and PO line items reference Product2.

Striven's GL Chart of Accounts has no native Salesforce equivalent and is migrated to a custom object Chart_of_Accounts__c. Each account record carries the account number (Account_Number__c), name, type (Asset, Liability, Equity, Revenue, Expense), and parent reference. This object is the hard prerequisite for all financial record imports and must be fully loaded and reconciled before Invoices, Bills, or account balances are touched. Account numbers serve as the external lookup key for all accounting records.

Open Striven Invoices migrate to Salesforce Opportunity representing the billing event. Invoice line items map to OpportunityLineItem with the resolved Pricebook2 and Product2 references. The original invoice date, due date, total amount, and balance due migrate to custom Opportunity fields. Convenience Fee and Discount configurations tied to Striven payment methods do not migrate and must be manually reconfigured in Salesforce payment settings post-cutover.

Striven Bills migrate to a custom Purchase_Order__c object or to Opportunity with a PO record type depending on the customer's reporting needs. The vendor link resolves to the Account (Vendor Type) created earlier. Line items migrate from Striven Bill detail rows with Items resolved to Product2. Tax codes and payment terms that differ between Striven and Salesforce require field-level mapping review during scoping.

Striven Sales Orders map to Salesforce Opportunity with a custom record type (e.g., Sales_Order). Status from Striven (Draft, Pending, Approved, Fulfilled) migrates to a custom status field. Order type that drives custom field visibility in Striven requires type-level field mapping adjustments in Salesforce where the equivalent custom fields are scoped to the record type.

Striven Purchase Orders migrate to the same custom Purchase_Order__c object as Bills if the customer uses a unified PO object, or as a separate record type. The vendor reference resolves to the Account (Vendor Type). Approval workflows attached to Purchase Orders in Striven are not importable and must be rebuilt in Salesforce Flow post-migration. PO line items resolve Items to Product2 and carry quantity, unit cost, and GL account reference from the Chart_of_Accounts__c mapping.

Striven Projects migrate to Salesforce's standard Project object (available with some Salesforce editions and Salesforce Cloud for Industries) or to a custom Project__c object. Project phases and milestones map to child records with their own custom fields. Custom field mapping per project type is required because Striven project structures vary by customer implementation. We audit the project schema during discovery before designing the destination structure.

Striven Tasks under Projects migrate as Salesforce Task records with the WhatId pointing to the parent Project record. Assignees resolve to Salesforce User via the Employee-to-User mapping. Subtask hierarchies and dependency relationships require explicit mapping work and may need to be represented as custom fields or related lists in Salesforce since the native Task object does not support hierarchical nesting.

Striven Fixed Assets include depreciation schedules and methods that have no native Salesforce equivalent. We migrate asset records and current book values to a custom Fixed_Asset__c object with custom fields for depreciation_method__c, accumulated_depreciation__c, and useful_life_months__c. The destination system's depreciation engine may differ and requires the customer's finance team to validate after migration. Asset-to-GL-account lookups reference the Chart_of_Accounts__c custom object.

Document attachments linked to Striven entities migrate as ContentDocumentLink association metadata without the binary files themselves. We export the document association (which entity it is attached to, the original filename, and the link date) and create ContentDocumentLink records in Salesforce pointing to placeholder ContentDocument records. If the customer's Striven instance exposes a file export path, we migrate the binary files as Salesforce Files; otherwise, the customer moves files through their own storage system post-migration.

Striven distinguishes global-level Custom Fields (visible on all records of a type) and type-level Custom Fields (scoped to specific entity subtypes). We audit the full custom field schema during discovery to determine which fields are global versus type-level, then map each to the correct Salesforce field on the corresponding object. Type-level fields that reference Striven-specific subtypes (e.g., Sales Order Types) require custom field creation scoped to the relevant Salesforce record type.