Migrate from Perfect Portal to Salesforce Sales Cloud

Perfect Portal clients map directly to Salesforce Accounts. Client name maps to Account.Name, website to Account.Website, and address fields to the standard address composite. Parent company hierarchies in Perfect Portal are preserved via Account.ParentId, ensuring multi‑tier organizational structures are retained. The original Perfect Portal client ID is stored in a custom Source_System_ID__c field for traceability and delta‑run matching.

Perfect Portal contact records — client representatives, matter participants, and other stakeholders — map to Salesforce Contacts. Core fields such as name, email, phone, and title map to the standard Contact fields, and each Contact is linked to its parent Account via AccountId. The parent Client must be migrated before Contacts to satisfy the lookup requirement. The original Perfect Portal contact ID is stored in a custom Source_System_ID__c field for reconciliation and future delta runs.

Perfect Portal matters map to Salesforce Cases, translating the portal's matter structure into the CRM's case model. The matter name maps to Case.Subject, the description to Case.Description, and the portal matter ID is stored in Source_System_ID__c for traceability. The parent Account is linked via Case.AccountId, and the matter stage is translated to Case.Status using a value‑mapping table. Case.Origin defaults to 'Portal Migration' to flag migrated records, and any custom matter properties become custom fields on the Case object.

Perfect Portal matter stage values — such as Intake, In Progress, Pending Review, and Closed — map to corresponding Salesforce Case Status pick‑list values through a value‑by‑value translation. The mapping table is defined during the discovery phase, and any custom status values that do not already exist in Salesforce are created before migration begins. This ensures that stage data is preserved accurately and that Case.Status can be set without validation errors.

Perfect Portal documents are downloaded and re‑uploaded as Salesforce Files using the ContentVersion/ContentDocument model. The document title maps to ContentVersion.Title, the file type to ContentVersion.FileType, and the file size to ContentVersion.ContentSize, preserving all original metadata. The file binary is stored in Salesforce Files storage, and the document is linked to the parent Case via ContentDocumentLink so it appears alongside the migrated matter. A custom reference field stores the original portal file URL for audit traceability.

Perfect Portal tasks map directly to Salesforce Tasks, preserving the core task attributes. The task subject maps to Task.Subject, the due date to Task.ActivityDate, and the status (Open or Completed) to Task.Status using a value‑mapping table. The task description is transferred to Task.Description, and priority is carried over if defined. Owner resolution occurs by matching the portal user’s email to a Salesforce User record; unmatched owners are flagged for fallback assignment before the migration batch runs.

Perfect Portal interaction logs — call logs, meeting notes, email threads — map to Salesforce Tasks with Type='Interaction'. The original timestamp is preserved as Task.ActivityDate, and the interaction content is stored in Task.Description. Each Task requires a parent Contact or Case, resolved during migration by linking to the appropriate ContactId or CaseId; any unresolved tasks are flagged for manual assignment to prevent loss of history.

Perfect Portal custom matter fields — such as Matter Type, Practice Area, Billable Hours — become Salesforce custom fields on the Case object using the __c suffix. The data type is preserved, and pick‑list values are migrated after the pick‑list is created in Salesforce. FlitStack AI delivers a field creation plan with each field’s API name, data type, and pick‑list setup requirements so the org is ready before data load.

Perfect Portal custom client fields — such as industry classifications, client tier, and portal‑specific flags — become Salesforce custom fields on the Account object using the __c suffix. The data type is preserved, and pick‑list values are migrated after the pick‑list is created in Salesforce. FlitStack AI delivers a field creation plan listing API name, data type, and pick‑list setup so the org is configured before client data is loaded.

Document‑level metadata — including title, file type, and size — maps to ContentVersion.Title, ContentVersion.FileType, and ContentVersion.ContentSize respectively, preserving the original document properties within Salesforce. The binary file itself is downloaded from Perfect Portal and re‑uploaded into Salesforce Files storage, where it is linked to the parent Case via ContentDocumentLink. A custom reference field captures the original portal file URL for audit traceability.

Perfect Portal owners and assigned users are resolved by matching their email addresses to Salesforce User records. Unmatched owners are flagged before migration so your team can either invite them to Salesforce or reassign their records to a fallback owner, ensuring every record has a valid OwnerId and traceability to the original portal user.

Perfect Portal integrations and third‑party connections — such as billing systems, document management platforms, and any linked services — cannot migrate because they are built on portal‑specific configurations. These integrations must be re‑established manually after the migration. FlitStack AI documents each connected system in the migration plan, including the integration type, endpoint URLs, and any required credentials, so your team can re‑configure them in Salesforce or through middleware after go‑live.

Portal workflows and automation triggers do not migrate because they rely on portal‑specific logic that has no direct equivalent in Salesforce. FlitStack AI extracts the workflow definition — including trigger events, conditions, actions — and delivers it as a written reference document. Your Salesforce admin uses this reference to rebuild the logic in Flow or Apex, and the non‑migrated nature of these assets is disclosed in the migration plan.

Portal user access roles, permissions, and sharing rules are portal‑level constructs with no direct equivalent in Salesforce. Salesforce manages access through Profiles, Permission Sets, and Sharing Rules, which must be configured after migration. FlitStack AI maps the portal’s role hierarchy to Salesforce Profiles and Permission Sets and delivers an access‑control plan so your admin can assign appropriate permissions based on your organization’s requirements.

If Perfect Portal stores parent‑client or company hierarchy relationships, these are mapped to Salesforce Account.ParentId, preserving multi‑level organizational structures. Parent accounts must be migrated before child accounts so the lookup resolves correctly during the migration run. FlitStack AI sequences the load order to ensure that each child account references a valid parent AccountId, and any hierarchy anomalies are flagged for review before the next batch begins.

Matter‑level billing data — such as hourly rate, cost, and invoiced amount — has no native equivalent in Salesforce’s standard data model. These values are migrated as custom Number fields on the Case object (e.g., Hourly_Rate__c, Cost__c, Invoiced_Amount__c) to preserve reporting continuity. They do not integrate with Salesforce’s native billing or invoicing features; your team uses them solely for historical reporting and analysis after migration.

FlitStack AI stores the original Perfect Portal client ID, matter ID, and document ID as custom text fields on the corresponding Salesforce records — for example, Source_Client_ID__c on Account, Source_Matter_ID__c on Case, and Source_Document_ID__c on ContentVersion. These fields enable delta‑run de‑duplication, allowing the migration tool to identify and update existing records rather than creating duplicates on subsequent runs, and they provide full traceability back to the source Perfect Portal data.