Software Upgrades

Upgrades fail when they are treated as a maintenance activity. On operator estates they are programme work. MongoDB, Sugar CRM, campaign, loyalty, and revenue and billing all have vendor clocks. Innova Core Technologies sequences those clocks from Riyadh so a version move does not strand a customer mid-journey.

We work inside Data, Integration, Customer Experience, and Automation programmes. An upgrade that only the platform owner loves will be rolled back by the first CX defect. An upgrade that CX loves but security did not review will become an access incident. Certified, repeatable delivery means freeze, test, cutover, and rollback are written before anyone books the change window.

What we upgrade, and why sequence matters

Database, middleware, and application moves are in scope when they sit under a customer programme. We do not treat a MongoDB cluster move as a DBA-only weekend if campaign and loyalty read from it. We do not treat a Sugar CRM version as an IT hygiene task if care is live on it. We do not treat an RBM patch as BSS-only if digital can still grant an offer that the old product catalogue understood differently.

Vendor support is a constraint, not a brochure. The version you want and the version your partner will still support are not always the same. We map that before the date is announced. Where Microsoft, Oracle, IBM, MongoDB, or the BSS partner already defines a supported path, we follow it. Inventing a skip-release because a slide said “latest” is how you lose the support ticket you will need at two in the morning.

Freeze, test, rollback

A freeze window is a commercial decision. Marketing, care, and BSS have to agree what will not change. We write that list. Testing follows real journeys: a prepaid offer, a CRM case, a loyalty earn, a bill. Functional, integration, and security cases travel together. A privilege model that changed with the new version is a test case, not a surprise. Data security belongs in the upgrade plan from week one.

Rollback has to be rehearsed, not hoped. Restore points, feature flags where the platform allows them, and a decision owner who can call the back-out without a committee at midnight — those are delivery artefacts. We write the runbook operations will use the next time the vendor ships a required patch. If the runbook only exists in the project team’s heads, the upgrade was not finished.

Lower environments must be close enough to teach you something. A successful upgrade in a sandbox that does not resemble production identifiers, volumes, or integrations is a rehearsal of the wrong play. We are explicit about what the lower environment cannot prove, so the steering committee is not sold a certainty nobody has.

Handover

After cutover, operations should know the new version, the support path, the remaining defects, and the next freeze. Hypercare is time-boxed and evidenced: which journeys were rerun, which defects remain, who owns each one. A silent week after go-live is not proof of success if nobody ran the pack.

We treat documentation as part of the upgrade, not a leftover. Release notes that matter are the ones operations will actually open: what changed for campaign grants, what changed for CRM access, what changed for rating. Vendor PDFs stay attached. The operating note is ours. If a joiner cannot find the freeze calendar and the rollback owner in one place, the upgrade is not finished.

We have sat with operators and integrators including Systems Arabia, STC, Zain KSA, Mobily, Airtel, Maalim Al Khabra, and Smart Solutions. The lesson is the same: upgrades that share a calendar with CX programmes survive. Upgrades that steal a weekend do not.

If a vendor clock is already ticking on MongoDB, CRM, campaign, loyalty, or RBM, tell us the programme and a window that works. A coordinator in Riyadh will return the request.

Request a Callback Testing All services