Migrate from Web+Center to Salesforce Service Cloud

Web+Center Incidents map to Salesforce Case. We extract status, priority, category, subcategory, assigned technician, and creation timestamp from the source database. Custom Incident fields (which vary per deployment) receive explicit field-to-field mapping to Salesforce Casecustomfields or a custom field set. The Incident number becomes Case CaseNumber for reference. Web+Center category and subcategory values migrate as Case Type and Reason picklist values, with inactive source values flagged for admin review.

Web+Center stores ticket conversation entries as IncidentDetail records linked to the parent Incident. These map to Salesforce EmailMessage records linked to the Case. Incoming customer replies become EmailMessage with Direction=Incoming; agent responses become Direction=Outgoing. HTML email body from Web+Center migrates to EmailMessage HtmlBody. We set the WhoId on EmailMessage to the migrated Contact record so the conversation threads appear on the Contact timeline.

Web+Center Customer records map to Salesforce Contact. Email address, phone number, first name, last name, and portal preferences migrate directly. Web+Center stores customer type (internal/external) which we map to a custom Contact field. Customers associated to a Web+Center Company record resolve to a Contact with AccountId set to the mapped Account record.

Web+Center Company records map to Salesforce Account. Company name becomes Account Name. Web+Center's account manager assignment migrates to Account Owner. Companies linked to multiple Customers preserve the 1:N relationship via the AccountId lookup on Contact. If the source has duplicate Companies with slightly different names, we flag these for deduplication before insert.

Web+Center Asset records (hardware and software inventory with serial numbers, purchase dates, warranty expiration, and assignment) map to Salesforce Asset. The AccountId on Asset resolves to the mapped Account record. Custom asset classification fields migrate to Asset custom fields. Serial number and product name map to Name and Product2Id respectively, with Product2 records created during migration if they do not exist in the destination org.

Web+Center KB articles use a proprietary content format. We extract text content and any embedded attachment references, then create Salesforce KnowledgeArticleVersion records. HTML formatting requires post-migration review; inline images may need re-embedding. Salesforce Knowledge must be enabled in the destination org (available from Enterprise tier and above) before article import begins.

Web+Center stores file attachments on the server filesystem with database path references. We resolve each file path, extract the binary content, and re-upload via Salesforce ContentVersion. We preserve the original filename and MIME type. A pre-migration path validation step identifies orphaned references where the source file has been moved or deleted without a database update. Any broken references are reported before migration begins so the customer can decide whether to exclude those records.

Web+Center maintains its own agent and administrator user directory. We export user records and map them to Salesforce User by email address. Password hashes do not migrate for security reasons; agents receive Salesforce welcome emails to set their own credentials. Web+Center role (technician, administrator, viewer) maps to a Salesforce Profile and Permission Set assignment determined during scoping.

Web+Center categories, subcategories, and priority levels are stored as lookup tables. We extract all active and inactive values and map them to Salesforce Case picklist fields (Type, Reason, Priority). Some Web+Center category values may not have a direct Salesforce equivalent; we flag these for admin review and map to a generic Other value with the original category preserved in a custom field for later cleanup.

Web+Center allows administrators to add custom fields to Incidents beyond the standard set. One deployment may have 12 custom fields and another may have 47. We inventory all custom fields during discovery, map each to a Salesforce Case custom field (or Casecustomfield if the destination has Field Service licensed), and flag any field types without a Salesforce equivalent (e.g., a multi-select picklist that exceeds Salesforce's picklist value limit) for discussion during scoping.