Salesforce to Creatio Migration: Complete Business and Technical Checklist

A project plan tells you what to do and when. A checklist tells you what not to forget. In a Salesforce to Creatio migration, what you forget is what breaks. The forgotten custom object that holds critical business logic. The forgotten integration that feeds nightly batch data from the ERP. The forgotten user who only logs in once a quarter but whose workflow depends on a specific report that nobody else uses. A plan without a checklist is a schedule for discovering what you missed during UAT — when it is too late to fix without delaying go-live.

I have led migrations from Salesforce to Creatio across banking, insurance, FMCG, and recruitment. Every migration has its unique complexity — the custom Apex code that was built five years ago by a developer who left the company, the AppExchange package that is no longer supported but still processes critical data, the integration that someone configured during a weekend maintenance window and never documented. The specific surprises are different. The categories of surprises are the same. This checklist is organized around those categories — so that you find the surprises during discovery, not during UAT.

The checklist is structured across seven phases: discovery and inventory, data profiling and quality assessment, data mapping and transformation design, platform configuration and customization, integration redesign, UAT and business validation, and post-go-live stabilization and decommissioning. Each phase includes specific checks, each with a clear pass/fail criterion. The checks are designed to be executed by a migration team that includes business stakeholders, not just technical resources. The goal is not to complete 100 percent of checks. It is to know which checks you failed and to make an explicit, documented decision about whether that failure blocks go-live or is an acceptable risk.

Use this checklist as a living document. Start it during the sales cycle — the discovery phase of the checklist is also the discovery phase of the implementation proposal. Update it during each phase of the migration. Review it at each stage gate. And do not archive it after go-live. The post-go-live checks continue for months after the migration. The checklist is the institutional memory of what was done, what was skipped, and why.

The discovery phase answers one question: what exactly are we migrating? This sounds simple. It is not. Salesforce instances accumulate configuration debt over years. Features are configured, used for a quarter, and abandoned. Custom objects are built for projects that were cancelled. Workflows are created that fire on conditions that no longer occur. Reports exist that nobody has run in two years. Integrations connect to systems that were decommissioned three years ago. The Salesforce instance has more objects, fields, workflows, reports, and integrations than anyone in the organization knows about.

The discovery inventory must be exhaustive. Every standard object used. Every custom object and its relationships. Every field — including formula fields, roll-up summary fields, and fields hidden from all page layouts. Every workflow rule, process builder flow, and flow (Salesforce's automation tools have evolved through multiple generations, and a single org may have automations built in all three). Every validation rule. Every approval process. Every report and dashboard — and, critically, every scheduled report and every report subscription. Every email template, email alert, and outbound message. Every Apex class, Apex trigger, and Visualforce page. Every managed package and every unmanaged package. Every integration — including the ones that are not documented, the ones that run on a schedule nobody monitors, and the ones that use a service account whose password nobody remembers.

The discovery also covers usage patterns, not just configuration. Which objects have records created in the last 90 days? Which fields have values in at least 10 percent of records? Which reports were run in the last 90 days? Which users logged in in the last 90 days? Configuration that exists but is not used is configuration that does not need to be migrated. Identifying it early reduces migration scope and cost.

Data profiling answers the question: how clean is the data we are about to migrate? Most organizations assume their Salesforce data is clean because it is in Salesforce — a CRM, after all, is supposed to be the system of record. The assumption is wrong. Salesforce data accumulates duplicates, incomplete records, inconsistent picklist values, orphaned child records, and data that violates business rules — all of which persist because nobody runs regular data quality reports.

Data profiling is not data cleansing. Profiling identifies what is wrong. Cleansing fixes it. The profiling phase should produce a data quality report that quantifies the problems: how many duplicate accounts, how many contacts without an associated account, how many opportunities with no close date, how many records with picklist values that do not match the picklist options. The cleansing phase fixes the problems that matter — and the definition of 'matter' should be a business decision, not a technical one. Some data quality issues are cosmetic. Some would break business processes if migrated. The profiling report gives the business the information it needs to decide.

Data profiling must cover all objects being migrated, but prioritize the objects that drive business operations: accounts, contacts, leads, opportunities, cases, and any custom objects central to business processes. For each object, the profiling should cover: completeness (what percentage of records have values in critical fields), uniqueness (are there duplicates, and if so, how many and what are the duplicate criteria), consistency (do picklist values match the defined options, do date fields contain valid dates, do related records reference existing parent records), and accuracy (do records match external data sources where those exist — for example, do account names match the official company names in the ERP).

Data mapping answers the question: where does each piece of Salesforce data go in Creatio? This is not a one-to-one mapping exercise. Salesforce and Creatio have different data models. Salesforce uses a lead-contact-account-opportunity model with a hard lead conversion process. Creatio uses a more flexible contact-account-opportunity model where leads are a state, not a separate object that disappears on conversion. The mapping must reflect these structural differences.

The mapping exercise must cover every field for every object being migrated. The source field (Salesforce API name) maps to the destination field (Creatio column name) with a transformation rule. The transformation rule may be direct (value copies as-is), transformed (value is modified — date format conversion, picklist value mapping, formula field dissolution into stored values), conditional (value is mapped differently based on conditions — for example, record type 'Partner' maps to account type 'Partner', 'Customer' maps to 'Client'), or defaulted (no source value exists, use a defined default).

Lead conversion is the most complex mapping challenge in a Salesforce to Creatio migration. Salesforce converts leads into accounts, contacts, and optionally opportunities. The conversion is a destructive operation — the lead record becomes 'converted' and is no longer editable. The lead's field values are copied to the new account, contact, and opportunity records based on field mappings configured in Salesforce setup. Creatio does not have a lead conversion process in the same sense. Leads in Creatio are contact records with a 'lead' type — they are qualified, not converted. When a lead is qualified, the contact record type changes from 'lead' to 'contact' and an opportunity is created. The data mapping must handle this structural difference: converted Salesforce leads become contacts with qualification data, and the associated accounts and opportunities must be recreated from the lead conversion data.

The output of the mapping phase is a mapping document — a spreadsheet that lists every source field, its destination, its transformation rule, and any notes about mapping decisions or exceptions. The mapping document is the contract between the business (who defines what the data means) and the technical team (who implements the mapping). Both parties must review and sign off before migration development begins.

The remaining phases — platform configuration, integration redesign, UAT, and post-go-live stabilization — are where the checklist prevents the failures that most migrations experience. Phase 4 (Platform Configuration and Customization) is about building the Creatio instance to match the requirements defined in discovery and mapping. Phase 5 (Integration Redesign) is about rebuilding the connections between Creatio and the external systems that Salesforce was connected to. Phase 6 (UAT and Business Validation) is about verifying that the migrated system works — not that it technically functions, but that the business can operate with it. Phase 7 (Post-Go-Live Stabilization and Decommissioning) is about supporting users, fixing issues, and eventually turning off Salesforce.

Platform configuration in Creatio is fundamentally different from Salesforce configuration. Creatio uses a low-code configuration model with C# for extensions. Salesforce uses a combination of point-and-click configuration (workflow rules, process builder, flows) and programmatic development (Apex, Visualforce, Lightning Web Components). The configuration phase must recreate Salesforce functionality using Creatio's tools — which means redesigning, not replicating. An Apex trigger that fires on opportunity update in Salesforce becomes a Creatio business process or a C# event handler. A Visualforce page becomes a Creatio Freedom UI page. The logic is the same. The implementation is different. Attempting to replicate Salesforce's implementation approach in Creatio creates technical debt. Redesigning the functionality for Creatio's architecture creates a cleaner, more maintainable system.

Integration redesign is frequently the longest phase because every integration must be rebuilt. The Salesforce APIs (REST, SOAP, Bulk, Streaming) are replaced by Creatio's APIs (OData, web services). Authentication models change. Data formats change. Error handling patterns change. The integration checklist ensures that every integration is identified, redesigned, tested, and documented — and that no integration is forgotten because it was configured years ago by someone who left no documentation.

UAT is the phase where the business validates that the migrated system is fit for purpose. The UAT checklist structures the validation: every business process is tested end-to-end, every report is verified against Salesforce data, every integration is confirmed to be functioning, every user role is tested for access to the correct data and functionality. UAT is not a demonstration of the system. It is a structured attempt to break it — to find the edge cases, the missing data, the broken workflows, the confusing experiences. A UAT that finds no issues is a UAT that was not rigorous enough.