The vast majority of tech tools that will one day run the company have to merge with a sprawling, customized, organization-specific infrastructure that has grown for decades with countless, fast, often unscripted changes. Tiny mistakes, the kind that are nearly impossible to avoid in complex human systems, can easily propagate into meltdowns.
Map Every Dependency Before You Touch Anything
The systems at the core of your business don’t exist in a vacuum. That ERP behemoth you’re thinking of upgrading (whether it’s SAP, Oracle, or another flavor) is linked to payment gateways, order processing systems, HR databases, and likely a myriad tools and systems you’re not even aware of. Most of us have inherited this stuff from others, who also left us with absolutely no documentation.
Even when you do know what’s connected, it’s not always as simple as looking up the phone number for the CTO at the company you’re about to buy software from and asking them if all their stuff will play nice with yours.
“No worries,” they’ll tell you, figurative arm around your shoulder. “We integrate with everything!”
What they mean is they integrate with everything. They have no idea if you can integrate with them. Or what it will cost. Or if it will even work.
Fix Your Data Before You Move It
Moving data that has errors or quality issues between systems only replicates and potentially exacerbates those issues. If you have duplicates in the old database, you will have duplicates in the new one. Invalid cell entries become invalid records, and orphaned transactions are orphaned in the new system too.
This part of the process is much harder than people like to admit. At the risk of generalizing, most developers and technology partners are fine so long as the data migrates from A to B and they have a list of records that made the jump. Whether they account for corresponding records in subtables, or manage record relationships changing in the new model, the response is usually a shrug and ‘yeah, that should be straightforward’. Guess where most migration issues arise?
Build A Decoupled Integration Layer
When doing a major upgrade there’s a widespread tendency to get rid of the old system completely and replace it with a new one. Unfortunately, this approach often fails.
If you replace everything at once you effectively create a single point of failure. A better alternative is to develop an API integration layer on top of the database that allows you to onboard new or modified tools without having to phase out the old ones. Newly integrated or replaced modules do not interact directly with the main database. Instead, they connect to the API integration layer, which ensures that they operate in parallel with the existing infrastructure. Poorly performing components can be disconnected and replaced or modified without affecting the legacy base.
Treat AI and Automation As A Separate Workstream
Integrating AI into existing systems often increases costs and timescales beyond expectations. AI tools don’t simply graduate from a research lab to a business application with minimal fanfare. When you’re scoping ai implementation challenges as part of a broader upgrade, treat them as a parallel workstream with their own timeline and their own resource requirements. AI and ML tools have ongoing resource requirements that extend beyond implementation into maintenance, monitoring, and eventually into replacement or iterative development of the tools themselves. Existing tools in an organization may not have those ongoing costs for things like monitoring or retraining; the invoice for their infrastructure requirements may be due to accounting, but they don’t need active management to remain the biggest kids on the block forever.
Run Parallel Environments During Testing
Before you cut over, run both systems simultaneously under real-world load. Not test data – actual operational traffic, validated against both environments to confirm the outputs match.
Parallel processing catches the errors that structured test cases miss. It shows you where the new system interprets data differently, where latency becomes an issue under volume, and where user behavior creates edge cases nobody anticipated. This phase should last long enough to cover your operational cycle – if your business has monthly close processes or quarterly peaks, the parallel environment needs to reflect those.
Uptime is the metric everyone watches during this phase. Track it honestly.
Define Rollback Triggers Before You Need Them
Failure thresholds must be defined in advance; general qualifiers like “if there are significant issues” DO NOT COUNT. These must be specific, measurable metrics that, once breached, automatically switch the lights off in the new environment and redirect all traffic back to the old one. This number must be set in advance – for all the regions, clients, or products you divided the rollout into. Meaning if there’s a problem, CEO, you see a red light before you even leave your office.
For each generalized risk, candidates for automatic rollback could include:
- Experiencing X number of alerts in monitoring tools for Y number of minutes
- Receiving A number of helpdesk tickets/calls of importance C
- A cross-functional team reviewing the situation and reaching consensus
- A subset of known customers raising the issue
- End-users encountering E number of issues of category F
- Decline of performance of Z percentage on key business function K
Preparation Is The Upgrade
You can’t go around the dependency audit, the data cleansing, the API architecture work, or the parallel testing phase. These are the work streams that go live in four months. No one wants to wait that long for a tangible ‘thing delivery’ and faced with a trade-off between bringing one of those forward vs. bringing one of the foundation elements back, it’s a tall order to keep their priority intact.
