Salesforce data operations
Salesforce data quality and migration work should make ownership, mapping, duplicates, validation, reconciliation, access, cutover, rollback, and follow-up visible.
State the business outcome, supported scope, accountable owner, acceptance condition, and what requires another service. The Salesforce implementation route provides an internal delivery path.
Record only the context that changes routing, authority, data quality, approval, fulfilment, or review. Name the receiving owner and return condition.
Define missing data, conflicting records, rejected work, unavailable systems, escalation, reconciliation, and evidence. Review the boundary when the service or data model changes.
Review user questions, repeated corrections, unowned dependencies, failed handoffs, and work outside the intended process.
A workflow is supportable when its purpose, authority, access, exception path, evidence, and support owner are clear.
Every Salesforce data migration raises the same early question: should the data be cleaned in the source systems before it is loaded, or should the cleaning happen as part of the load? The honest answer is that both happen, and the balance depends on where the defects sit. Defects that change the meaning of a record, such as an account that is really two companies, need a decision by the data owner before anything is moved. Defects that are mechanical, such as inconsistent date formats or trailing spaces in a postal code field, can be corrected by the transformation step if the rule is written down and tested. Treating every defect the same way is a common cause of a migration that moves problems across intact.
The buyer should ask the provider to separate the two groups in the first assessment. The first group is a list of decisions for the client. The second is a list of transformation rules that the team will apply and test. Mixing them makes it impossible to tell later whether a bad record was lost in the transformation or was never right in the source. The related data migration and integration page covers cleaning, standardizing and transforming data and deduplication for Salesforce.
Salesforce records are connected. Contacts belong to accounts, opportunities belong to accounts and carry line items, cases refer to contacts and products, and custom objects may point to any of them. A load that ignores this structure will fail on the first child record that refers to a parent not yet created. The load sequence therefore has to follow the dependency tree, from the records that stand alone, such as users, products and price books, through accounts, then contacts, then transactional records. Each stage must reconcile before the next begins.
The external identifier is the mechanism that makes this workable. Each source record should carry a stable key from its original system, stored in a dedicated field in Salesforce. That key allows a later load to find and update an existing record rather than create a duplicate, and it allows reconciliation to trace any record back to its origin. Buyers should ask whether every object in scope will receive an external identifier, and who will hold the mapping between the old keys and the new record identifiers after cutover.
There are three common ways to cut over, and each has a different risk profile. A single cutover moves everything in one event, usually over a weekend, and returns the business to a single system quickly. It is simple to explain but leaves little room for correction if the load reveals a major problem. A phased cutover moves one business area or one object group at a time, which reduces the size of each failure but requires a period in which two systems hold parts of the same process. A parallel run keeps the old system live while the new one is tested against it, which gives strong evidence but adds the effort of maintaining both.
| Approach | Fits when | Main exposure | Evidence needed before go-live |
|---|---|---|---|
| Single cutover | The data volume is manageable and the business can pause new work for a defined window | A late defect leaves little time to recover | Full dress rehearsals with reconciled counts |
| Phased by business area | Teams can work in different systems for a period without confusion | Cross-area records and reports break during coexistence | Dependency map showing which records cross the boundary |
| Parallel run | The process is high-value and errors are costly to users or customers | Two systems drift apart and staff must reconcile both | Agreed tolerance for differences and a retirement date |
The choice is a business decision because it determines who works in which system and for how long. A provider can recommend an approach, but the client must accept the operating burden of that approach, including the period during which users may need to look in two places.
Reconciliation is the discipline that separates a migration from a copy operation. It requires an agreed set of checks, run after each load and again after the cutover, with results recorded. The basic checks compare record counts by object and by status between the source and the target. The more useful checks compare totals that the business relies on, such as the value of open opportunities by stage, the number of active accounts by owner, or the balance of open cases by queue. A difference in any check is either explained and accepted by the data owner, or it is treated as a defect.
Where the same figures must also be kept current after the move, the data engineering and pipeline development page covers building data pipelines, which is relevant where checks need to run on a schedule. Sampling matters as well. A random sample of records, reviewed by the people who use them, will catch problems that counts cannot. A sales manager is likely to notice an opportunity attached to the wrong account in a way that no automated comparison would flag. The sample should be chosen by the business, not by the migration team, so that it reflects the records the business cares about.
Duplicate records are the most visible data problem after a migration, and the most tempting to remove automatically. Automatic merging is risky because two records that look identical may carry different histories, different owners or different contractual relationships. The safer design is to use matching rules to flag probable duplicates, to route the flagged groups to the data owner for decision, and to merge only the groups where the owner has confirmed the outcome. Where volumes are large, the owner can approve rules for clear cases, such as an exact match on a verified tax identifier, while the ambiguous cases stay in a review queue.
Where the same customer or asset record also lives in a service platform, the data governance and source authority page covers which source is authoritative for a field or relationship. Salesforce provides duplicate management features that can prevent new duplicates from being created after go-live. These should be configured with the same matching logic used in the migration, so that the rules applied during the move and the rules applied during daily use do not contradict each other.
For programs that move data into more than one platform, the ServiceNow data migration, reconciliation and cutover page covers reconciliation evidence for a ServiceNow target. A rollback plan answers a single question: what will the business do if the new system is not right on the day? The plan should name the conditions that trigger a rollback, the person who decides, the steps to restore the previous state, and the data that will be created in the new system during the window and must then be returned to the old one. Some teams write a rollback plan that cannot actually be executed, because the data created after cutover is not captured. The plan should be rehearsed, at least for the mechanical steps.
The first weeks after go-live need their own monitoring. Track user questions about missing or incorrect records, repeated corrections to the same field, and reports that the business does not believe. Each pattern points to a specific gap in the migration, and each should have a named owner for the fix. The migration is not complete when the load finishes. It is complete when the reconciled data supports the decisions that people make from it.
The answer should describe a quarantine process. Records that fail a rule should be held in a defined list with the reason for each failure, the owner who must decide, and the date by which a decision is needed. A provider who says all records will load without exception is describing a plan that has not yet met the data.
The client's data owner should own the mapping, and the provider should deliver it as a maintained document. Without it, later questions about a historical record cannot be answered quickly.
This must be decided explicitly, because attachments and activity history can be large and expensive to move. The decision should weigh the value of the history against the storage and performance cost, and should be recorded so that users know what they can and cannot find after cutover.
The scope of the data work is best settled during needs assessment and discovery, and the Salesforce services page shows the wider context. Before any load is scheduled, list the objects in scope, name the data owner for each, and identify the reports the business relies on most. Those three lists show where reconciliation effort must go. You can discuss your data migration requirements once those lists exist.
Bring the ownership, data, approval, or handoff question that needs a clearer operating model.
Discuss data migrationGuides from the Oblytech ServiceNow library that explain the practice behind this page.