Inheriting a Broken Salesforce
Migration, Governance, and Ongoing Architecture
Three years of stalled progress. Five integrated systems. 32,000 metadata changes. No documentation. I had never logged into a Salesforce instance in my life.
metadata changes migrated
downtime during cutover
integrated systems coordinated
of stalled progress resolved
The Short Version
An international organization had a Salesforce environment that hadn't moved in three years. I learned the platform from zero and delivered what three years of previous effort couldn't.
A multi-system integration project spanning Azure Entra ID, FormAssembly, WordPress, and a learning management system was mired in scope creep, had no documentation, and nobody fully understood the current state of the system. I forensically analyzed the environment, selected and executed a migration toolchain for over 32,000 metadata changes, and delivered a zero-downtime migration to production — coordinating across internal teams and external partners.
That was the project. What followed was the real work: an ongoing re-governance effort to fix the architectural decisions that made the migration necessary in the first place.
The Inheritance
Five systems. Eight redirects. Nobody knew why.
The integration was supposed to unify these systems. Instead, it had become a graveyard of partial implementations, undocumented customizations, and scope creep.
Salesforce
Central CRM
Azure Entra ID
Identity & SSO
FormAssembly
Data Collection
WordPress
Web Presence
LMS
Program Delivery
The SSO login flow alone spans four systems and eight redirects.
User clicks "login" on the portal. Gets redirected to Azure for authentication. Passes through four separate grants processes that phone back to Salesforce to verify permissions. Redirects to WordPress to sync grants with user accounts. Login completes. To access the LMS, the user clicks a link in the header — and gets redirected back to Azure for a second authentication round-trip. Then the LMS login completes — if the email addresses match.
A single user action. Eight redirects. Four systems. Nobody was entirely sure why all of them were necessary.
Learning the Platform
I did not know Salesforce.
No certifications, no training, no prior exposure. When I was assigned this project, I had to learn everything — the data model, the automation framework, the metadata architecture, Apex, Lightning Web Components, the deployment model, the ecosystem tooling — while simultaneously executing a high-stakes migration on the client's timeline.
This wasn't sequential. It was concurrent. I was learning the platform by forensically analyzing the broken environment I'd been asked to fix.
First Salesforce login. Ever.
Forensic analysis while learning the platform concurrently. Data model, Flows, Process Builder, metadata architecture.
Working proficiency. Building custom solutions, writing Apex, making architectural decisions with confidence.
Migration executed. Zero downtime. 32,000+ metadata changes deployed to production.
Genuine proficiency. Ongoing architecture, governance frameworks, LWC development. The "should I?" not just the "can I?"
Forensic Analysis
Before anything could move, I had to understand what existed.
No documentation. No architecture diagrams. No data dictionaries. No record of what had been customized, what was standard, and what was broken.
Metadata Mapping
Objects, fields, flows, process builders, validation rules, custom Apex, permission sets, profiles — the full landscape.
Active vs. Abandoned
Many automations had been built and abandoned without cleanup. Identifying what was live vs. dead was prerequisite to any migration.
Data Relationships
Traced the actual data model vs. the intended one. The gaps between these two told the story of every shortcut and workaround.
Integration Touchpoints
Documented every connection between Salesforce, Azure, FormAssembly, WordPress, and the LMS. What talks to what, through which mechanisms.
Technical Debt Inventory
Automations layered on automations. Data denormalized in ways that created maintenance nightmares. Processes enforced inconsistently.
Architecture Assessment
An environment built incrementally without architectural discipline. The analysis revealed the full scope of what needed to change.
The Migration
32,000 metadata changes. Zero margin for error.
I selected Gearset for its comparison capabilities and rollback features. A migration of this scale — touching objects, fields, flows, Apex, LWC components, permission sets, and integrations — had to be precise. A partial deployment or failed rollback meant downtime for the client's operations.
Deployment Sequence
Forms & Data Collection
FormAssembly workflows migrated in sync with their Salesforce counterparts — a form referencing a field that doesn't exist yet in production breaks immediately.
Flows & Automations
Dependencies on each other and on custom objects that needed to exist first. The ordering was surgical.
Azure B2C Scripts
Authentication and identity scripts coordinated with the Salesforce-side SSO configuration. The eight-redirect flow had to work end-to-end.
Third-Party Integrations
API endpoints, authentication tokens, webhook configurations — each with their own deployment considerations.
Production Cutover
Everything tested in sandbox first. The production deployment was zero downtime. All five systems functional post-migration.
The Real Work
The migration was the urgent project. The re-governance is the important one.
Migrating broken architecture to a new system doesn't fix the architecture. It just moves it.
Data Governance Failures
Fields that should have been required weren't. Picklists that should have been standardized weren't. Data entry was freeform where it should have been constrained.
Unenforced Business Processes
Workflows and validation rules existed but weren't consistently enforced. Users learned workarounds. The system told two different stories depending on how you queried it.
Complexity Spiral
Automations built to handle edge cases caused by missing governance. Each one added complexity. Each complexity created new edge cases. Users struggled, drove toward workarounds, creating more data quality issues.
A 30-minute fix that takes 16 hours.
An email field had been denormalized and replicated via Flows across related records, rather than being managed through proper data relationships. The Flows had poor edge-case coverage — the "same" email could be different across records depending on which one was updated most recently.
When I needed to change how that field was handled, what should have been a 30-minute modification turned into three hours of documenting impact and dependencies — and that was only possible because of a separate ten-hour remediation I'd completed earlier that week.
Bad data governance, poor systems design, and weak architectural discipline turned a 30-minute fix into a 16-hour project. This is the tax that compounds on every future change.
The Relationship
They didn't hire a Salesforce architect. They got one anyway.
The client originally engaged at 14 hours per week. Based on the quality of the migration work and the ongoing value of the architecture remediation, they expanded to 20 hours per week.
I now function as their Salesforce architect — not just maintaining the system, but actively improving its architecture, building governance frameworks, and serving as the technical authority on how their environment should evolve.
Hindsight
What I'd do differently.
Governance before migration.
I'd push harder for remediating the worst governance failures in sandbox before migrating to production. The counter-argument: the project had been stalled for three years. The client needed momentum. Delivering a working production system rebuilt the trust that made the ongoing governance work possible. Sometimes you ship what you have and fix it in place.
Document the integration surface earlier.
The five-system landscape was more complex than anyone realized. An integration map — what talks to what, through which mechanisms, with what authentication — would have saved time during migration sequencing. I built that documentation during the project. I should have demanded it as a prerequisite.
Internal Salesforce literacy sooner.
Some governance failures persist because the people entering data don't fully understand the data model. Training for end users — not just admin documentation — would accelerate the re-governance by reducing the rate at which new problems are introduced.
The Design Insight
The fix is never the migration.
Organizations buy a platform, customize it without architectural discipline, and hire someone to fix it years later when the complexity becomes unmanageable.
The migration is the thing that gets approved and funded because it has a clear scope and a deliverable. The real fix is the governance work that follows — the slow, unglamorous process of enforcing data standards, simplifying workflows, removing denormalized fields, and training users to work within the system instead of around it.
The skill isn't just knowing Salesforce. It's recognizing what went wrong architecturally, building a remediation plan that doesn't break the system people depend on today, and executing that plan incrementally while the organization continues to operate.
Technical Stack
More case studies
See how I approach different kinds of problems — from crisis infrastructure rescue to AI-driven workflow design.