Change Management for System Migrations
System migrations fail when teams overlook the operational details that separate smooth transitions from costly disruptions. This article compiles practical guidance from industry experts who have managed complex platform changes across regulated and high-stakes environments. The strategies presented address everything from carrier integrations and compliance protocols to authentication standards and project governance structures.
Unify Carrier Integrations And Configure Client Rules
We almost lost a six-figure client in month two because I customized something that should have been standardized.
When I built my 140,000 square foot 3PL facility, I had to migrate our entire warehouse management system while fulfilling 50,000 orders a week. The question wasn't just what to customize - it was which sacred cows to slaughter. Here's what I learned the expensive way.
I standardized receiving processes completely, even though three clients swore their products needed special handling. Turned out 90% of "special requirements" were just legacy habits from their previous warehouse. We built one rock-solid receiving workflow with quality checkpoints. That decision saved us from training nightmares and let new warehouse staff get productive in days instead of weeks.
The killer mistake? I customized our returns processing for each brand. Seemed smart at the time - give every client exactly what they want, right? Wrong. Six weeks after launch, we had seven different return workflows, staff constantly asking which process to use, and errors spiking. One beauty brand's returns were taking 11 days to process because their custom workflow required three separate system touches. We spent four months unwinding that mess and lost the client anyway.
The choice that saved us months of rework was standardizing carrier integration but customizing the business rules layer. We built one system that talked to all our carriers the same way, but let clients set their own rules for which carrier to use when. Sounds obvious now, but most 3PLs do the opposite - they hardcode business logic and try to customize technical integrations. That's backwards.
My rule now: Standardize anything that touches multiple systems or requires training. Customize only what directly impacts the customer experience and can be changed with configuration, not code. At Fulfill.com, I see brands make this same mistake when evaluating 3PLs - they demand customization in areas that don't matter and accept standardization where flexibility would actually help them grow.
Prioritize Volatility Map Edge Cases Early
The most useful filter before moving a core system is process volatility. If a process changes often because the market shifts or teams are still learning, we avoid hard customization. We keep the core system simple and allow flexibility through clear policies. If a process is stable like compliance or data ownership, we define it early and keep it fixed.
The decision that saved us time was mapping exceptions before workflows. Most teams start with the ideal process but we focused on where people skip steps or use manual workarounds. These exceptions showed how work actually happens. By building around real behavior, we avoided users recreating old habits in the new system.
Fix Compliance Protocols Before Expansion
Coming from a background in operations and business process work at Sage Warfield, then building GermPass from a garage prototype into a lab-certified medical-grade system, I've had to make this exact call repeatedly under real pressure.
The framework I use: standardize anything that touches regulatory exposure or third-party validation. For GermPass, that meant the UVC exposure cycle and log-reduction protocols were locked in stone before we ever approached an independent lab. Letting those drift would have invalidated our testing entirely and set us back years, not months.
The one decision that genuinely saved us from rework was standardizing our pathogen testing methodology before we scaled to multiple unit configurations. Because Dr. Kelly Bright's lab protocol was fixed early, when we expanded from one unit type to others, we weren't rebuilding the credibility of our results -- we were just replicating a trusted process.
What most people get wrong is treating compliance-adjacent processes as flexible because they feel internal. They're not internal -- they're the backbone everything else hangs off of. Customize your sales motion, your deployment workflow, your customer onboarding. But whatever a regulator, a lab, or a hospital infection control officer is going to scrutinize? That gets standardized first, before you scale anything.
Let User Behavior Guide Standards
The question everyone gets wrong is whether to standardize or customize. The real question is: who does this process actually serve? If the answer is internal comfort, that is a warning sign. If the answer is the person trying to get something done, you are on the right track.
I learned to let customer behavior make that call for me. When people move through a process with confidence, that tells you it works as a standard. When they hesitate, get confused, or ask the same questions over and over, that is a signal the process is not solving the right problem yet. Hesitation is data. Most teams just are not listening for it.
The one decision that saved us the most rework was choosing not to lock in our onboarding flow before we had enough real usage to know what people actually needed. We had internal opinions about how it should work. We held those loosely. We watched how nonprofit organizations, who are often juggling enormous responsibility with lean teams, actually moved through the product. That behavior told us what to standardize and what to keep flexible.
Founders who skip that observation phase and build to their own logic end up rebuilding later. The months you think you are saving by moving fast become the months you spend undoing decisions that felt right but were never tested against reality. Build with people, not ahead of them.
Adopt A Clean Ledger Structure Upfront
The decision between standardizing and customizing a core system process almost always gets made for the wrong reasons. Customization feels like a competitive advantage in the planning meeting and becomes technical debt in the implementation review. The processes worth customizing are the ones where the standard approach genuinely cannot serve the business outcome. Every other customization request is usually a preference wearing the language of necessity. The choice that saved months of rework was standardizing the chart of accounts structure entirely before migration rather than carrying forward the accumulated inconsistencies of the legacy system. The temptation was to preserve the existing structure to reduce disruption. The reality was that migrating a clean standard structure took three weeks longer upfront and saved four months of post-launch reconciliation work. The rule worth applying before every customization decision: is this genuinely different or just familiar. Familiar is the most expensive reason to customize a core system.
Protect Secret Sauce Harmonize Commodities
Many companies believe that the way they have been executing their business processes are one-of-a-kind, but many times they are performing in a specific way simply because that is how it has always been done. Therefore, I encourage all teams to look at what is unique to their business and what is not prior to initiating any migration project. Commodities (the non-core features of a company's creation) should be standardized prior to migration and only the "secret sauce" (the core items that give an organization's business model its competitive edge) should be customized.
Many years ago, my client insisted I create a custom travel expense approval process, but through discussion with them, we convinced them to use the existing configuration instead. This resulted in saving the company many months of development time after implementation because they no longer had to maintain a custom coding base that could not be modified, and required a third party for every little change. The greatest pitfall for companies transitioning to digital business models is the inability to improve dated processes through the implementation of a new software system simply because the new system is required to be like their old, broken processes we've used for years.
The objective of software customization should always be that of a scalpel versus that of a hammer. If a process does not provide a measureable competitive advantage, changing a team's behavior via training is often the most effective solution to improve an organization's performance versus modifying the software application used to execute the process. Treating standardized workflows as something that should be "fixed" through software code eliminates any future ability of the organization to possess the agility that digital systems were designed to produce.
Align Metrics Launch Modules First
I spent 20 years as a plant scheduler and operations manager before becoming VP at Lean Technologies, so I've lived through the pain of software that ignores shop floor reality. My rule is to standardize the **output**--the real-time metrics for dashboards--while customizing the **workflow** to fit your existing best processes rather than forcing your team to adapt to the tool.
One choice that saved us months of rework was the decision to launch modularly, starting only with high-pain areas like Maintenance or Quality instead of a full-system "big bang." Our partners at Assa Abloy used this approach to move from physical sticky notes to digital screens, ensuring the team actually owned the process before scaling.
This modular strategy prevents the common trap of managing a dozen unconnected apps while trying to fix everything at once. By prioritizing one Thrive module to start, you build immediate wins and avoid the technical debt of a failed enterprise-wide rollout.
Match Policy To Platform Capabilities
As President of Safe Harbors Travel Group, I've spent decades helping organizations transition from fragmented, "non-linear" travel setups to centralized global management systems. I've learned that deciding what to lock down and what to leave flexible is the difference between a system that scales and one that breaks.
I prioritize standardizing "Duty of Care" protocols and reporting structures because traveler safety and spend visibility must be absolute. I reserve customization for a company's unique culture, such as accommodating an NGO's specific dietary rules or choosing a "regulated honors system" for per diems rather than a one-size-fits-all punishment model.
One choice that saved us months of rework was mandating a "Match Your Policy With Your Technology" audit before launch. By rewriting the travel policy to align specifically with our automated expense system's capabilities, we avoided the massive friction caused when employees tried to use modern tech under guidelines written a decade ago.
Cement The Schema At Kickoff
We built memelord.com as a no-code MVP in three weeks, so we had to make fast decisions about what to standardize versus what to keep flexible. The rule: standardize anything you'll never compete on, customize anything that's the actual reason people pick you. Auth, billing, and infrastructure were all off-the-shelf. Nobody chooses a meme platform based on their checkout flow. But the meme editor, the trending alert system, the brand voice controls: that's where we went deep on custom, because that IS the product.
The one choice that saved us months of rework was standardizing our data model before writing a single feature. Two days upfront to agree on how content, users, and brand profiles relate to each other. Every feature we added after that clicked into the existing schema instead of requiring a migration. Teams that skip this step spend the next six months doing patchwork. Boring infrastructure should be boring and standard. Save your creativity for the things that actually differentiate you.
Enforce Consistent Estimation Inputs At Intake
My disciplined background in operations and the Navy taught me the critical importance of a robust framework. For core systems, I standardize processes that directly impact our core promises: accurate material estimation and reliable delivery. We customize the client-facing interactions and problem-solving to maintain our exceptional customer service.
One choice that saved us months of rework was standardizing the **data input and validation process for all material estimations** before migrating to a new ERP. We mandated using our professional estimation tools and specific data fields for all plans, regardless of the project size.
This ensured every estimate had consistent, high-quality data from the outset. Without this upstream standardization, migrating historical data and training our team on a new system would have been a tangled mess of incomplete or inconsistent project information, leading to massive reconciliation efforts post-launch.
Lock Weekly Priorities And Ownership
With 25 years in senior global leadership at HP and leading M&A integrations at Buy and Build Advisors, I've standardized processes across high-stakes transitions to ensure scalability without the founder.
Standardize high-volume, revenue-critical processes like lead handling, onboarding, and weekly priority reviews--these run best with checklists for consistency. Customize leadership roles or niche client adaptations where founder vision uniquely applies.
One choice that saved months of rework: Before a full leadership system rollout for a client scaling from $500K to $1M, we standardized a weekly review of just the top three priorities, owners, and "done" criteria first. This caught misalignment early, avoiding scattered execution and constant fixes post-launch.
Centralize Project Oversight Preserve Local Estimates
I lead a national platform that acquires regional firms like RBC Utilities and Foshee Construction, focusing on aligning high-performing teams with scalable systems. I prioritize standardizing the "financial and safety architecture"--the back-office functions that manage capital and risk--while customizing the field execution processes to protect the local culture.
We look for the intersection where national scale can solve local bottlenecks without erasing the identity of the people doing the work. In our acquisitions across the Piedmont Atlantic and Florida, we standardize reporting structures to ensure disciplined decision-making but allow regional leads to keep their specific site-prep workflows.
The choice that saved us months of rework was standardizing our project management onto **Procore** while intentionally leaving the regional estimating templates untouched. This allowed us to gain national visibility into project health immediately without breaking the bidding pipeline or forcing crews to relearn how they calculate earthwork costs.
By refusing to force a "one-size-fits-all" template onto the estimation phase, we avoided the massive data migration errors that usually cripple a transition. This balance allowed our partners to scale their operations using our capital and systems without losing the precision that earned their local market's trust.
Institutionalize GxP Controls Clone Validation Packs
With over 20 years guiding GxP validation for core systems in pharma and biotech, including co-founding CompliancePath and shaping Valkit.ai's roadmap, I apply risk-based principles from GAMP 5 and FDA CSA to decide.
We standardize universal GxP processes like automated traceability, audit trails, and risk assessments to ensure compliance scales without variation. We customize only asset-specific elements, such as tags for serial numbers or models in master data libraries.
One choice that saved months of rework: For SAP S/4HANA migrations, we standardized "golden" validation packages upfront and used cloning for iterative changes, letting tag updates cascade automatically instead of manual per-document tweaks. This prevented post-launch deviations and regression testing chaos seen in legacy tools.
Define Permissions And Stewardship Before Migration
I've been moving businesses through core IT changes since founding Impress Computers in 1993, including cloud and Microsoft 365/SharePoint migrations for firms that can't afford confusion, downtime, or "we'll fix it later." My rule is simple: standardize anything tied to security, access, recovery, and handoffs; customize only where the workflow is genuinely part of how the business wins.
Before a move, I ask three things: if this breaks, does work stop; if this varies by person, does risk go up; and if we customize it, who owns it a year from now? If the answer points to fragility, it gets standardized. That usually means identity, permissions, file structure, naming, approvals, backup behavior, and what "back to normal" actually means after an issue.
One choice that saved a lot of rework for us was standardizing permissions and ownership before migration instead of copying messy legacy access into the new system. When companies move file servers to SharePoint, the temptation is to preserve every exception; that just recreates the old bottleneck where only one person knows who can access what, and everyone waits on them.
In manufacturing and construction especially, I'd rather keep a necessary legacy workflow for a while than customize the new platform around bad habits. We've had better outcomes using a hybrid approach: protect the old system, clean up the process around it, and only customize after the team proves the exception is real and repeatable.
Start Minimal Prove Exceptions Later
Before moving a core system, I separate process steps into two buckets: what reflects real business logic and what reflects historical habit. That sounds obvious, but teams often defend old workarounds as if they are requirements.
We standardize the processes that should behave the same every time, especially around handoffs, approvals, naming conventions, and reporting fields. We customize only where the process directly protects margin, compliance, or customer experience. If a customization exists just because the old system was awkward, it is usually a trap.
One choice that saved us months was refusing to recreate every legacy exception on day one. We launched with a cleaner operating model and documented edge cases separately. That forced the team to prove which exceptions were actually common enough to deserve system logic.
Most migration pain comes from importing chaos with better software. The goal is not to preserve every quirk. It is to preserve what matters and retire what has been quietly slowing the business for years.
Establish Zero Trust Identity Baseline
I specialize in aligning IT with frameworks like CMMC 2.0 and HIPAA, focusing on making systems audit-ready from day one. My rule is to standardize every technical control required by the framework--like encryption and logging--while customizing the specific access layers to fit a company's unique WFH or hybrid reality.
One choice that saved us months of rework was standardizing identity via **Duo** as the primary gateway before migrating any core systems to Azure. By establishing this Zero Trust baseline first, we avoided the expensive nightmare of retrofitting multi-factor authentication and access policies onto dozens of individual apps once they were already live.
For instance, when managing the transition for National Billing Institute, we standardized their security and communication tools using **SentinelOne** and **ThreatLocker** simultaneously. Including "secondary" systems like VOIP and fax in the initial standardization prevented the common mistake of leaving legacy channels unmonitored, which usually leads to failed audits and massive remediation costs.
Set One Pipeline One Truth
Standardize the Core, Customize the Edge
Before moving any core system, I separate processes into two buckets - what must scale reliably and what actually creates differentiation. Most teams get this wrong by over-customizing early, thinking it will "fit better," but it usually creates long-term complexity.
My rule is simple -
If a process is repeatable across teams and doesn't directly impact customer experience, it gets standardized.
Anything that affects customer interaction, revenue flow, or decision-making flexibility gets considered for customization.
A real example was during a CRM and workflow migration. The initial push from the team was to customize pipelines, reporting formats, and automation flows for every use case. It felt logical because each team had slightly different needs.
Instead, we standardized the core structure -
1) one pipeline framework
2) one reporting format
3) one definition of key metrics
Then we allowed limited customization only at the edges - like custom tags, filters, and team-specific views.
The one decision that saved us months of rework was refusing to customize reporting logic early on. Everyone wanted their own version of dashboards, but we locked a single source of truth first.
Within a few weeks, teams adapted. More importantly, when we scaled, we didn't have to rebuild reporting or reconcile conflicting data definitions across teams.
I've seen the opposite happen too - where teams customize everything upfront and then spend months cleaning up inconsistencies after launch.
The key insight is this -
standardization reduces future friction, customization should earn its place.
If you standardize the foundation and customize only where it truly matters, you move faster now and avoid paying the cost later.
Conform Auth And Retries Across Stack
I build infrastructure where AI agents connect to hundreds of APIs simultaneously, so I've lived the standardize-vs-customize tension at an architectural level -- one wrong call and you're debugging auth failures across 250 integrations at once.
The framework I use: standardize anything that crosses a boundary you don't control, customize everything internal. For WithOne, that meant locking in a single, rigid authentication contract early -- every integration, regardless of quirks, had to conform to one auth interface. OAuth, API keys, bearer tokens -- all normalized before we touched customization anywhere else.
The specific decision that saved us months: we standardized error handling and retry behavior *at the platform level* before onboarding our first integration, not after. Every app gets the same retry logic, backoff, and failure state -- no exceptions. When we later added Shopify, Stripe, HubSpot, and 250 others, we never rewrote a single error handler. The customization lives in the action schemas themselves, which is isolated and cheap to change.
The trap is customizing the integration layer because every API feels unique. They do have quirks -- Gmail's 25MB limit, Jira's per-project custom fields -- but those belong in the knowledge layer, not the execution engine. Keep your execution engine boring and uniform.
