The Last Working Week: A Five-Day Cutover Runbook for Maximo 7.6.1.x to MAS 9.2

The Last Working Week: A Five-Day Cutover Runbook for Maximo 7.6.1.x to MAS 9.2Category: MAS Platform | Maximo Insider | September 20, 2026

On Sunday, September 20, the Maximo 7.6.1.x calendar reads ten days until extended support ends. That number is a comfort and a trap at the same time, because the calendar is not the constraint. The working calendar is. Monday September 21 through Friday September 25 gives you five full business days with staff online, change boards convening, application owners reachable, and vendors answering escalations. September 28 through 30 is a three-day short week that will be consumed almost entirely by final approvals, freeze enforcement, and the people who take the last week of the quarter off. Whatever a 7.6.1.x estate intends to prove about its cutover readiness before extended support ends on September 30, it has five days to prove it, and three of those five days are already spoken for by the release calendar most organizations carry into a quarter close.

The trap is the assumption that this week is for finishing an upgrade. In most 7.6.1.x estates that is not what the week is for, and organizations that treat it that way burn the last rehearsable window on activity that produces no evidence. For the much larger cohort that will not reach MAS 9.2 production before September 30, the week is for producing a defensible position: a documented risk position signed by the right people, a rehearsed cutover procedure that has been executed once against production-shape data, and an interim support posture that can be explained to an auditor in twelve months' time. For the small cohort that can genuinely land production inside the window, the week is for the final go or no-go gate and nothing else.

This runbook treats the five days as a sequence of gates rather than a to-do list. It assumes a 7.6.1.x estate on a conventional database with a mix of out-of-the-box and customized objects, at least one file-based integration interface, and a change board that meets weekly. It walks the five working days one at a time, then covers the three fallback postures that most late movers will actually need, and closes with the sequencing mistakes that turn a defensible position into an indefensible one. Where an estate cannot satisfy a gate, the runbook says so explicitly, because a failed gate on Wednesday September 23 is a manageable problem and the same failed gate on Tuesday September 29 is not.

Day One: The Entitlement and Exposure Baseline

Monday September 21 is the only day in this week where you can be wrong without consequence, which makes it the only correct day for the baseline. Everything downstream depends on two numbers that most 7.6.1.x estates have never actually calculated: what the platform entitlement currently covers, and what would break first if it stopped.

Start with entitlement, because the distinction between "Maximo stops working" and "IBM stops answering" is the single most frequently misreported fact in this cycle. Maximo 7.6 will not stop functioning on October 1, 2026. Licenses persist, logins persist, work orders persist, and a large population of environments will run into 2027 and beyond. What ends is the support entitlement: no more problem management records for newly discovered defects, no fixes or patches for defects found after the date, and no security responses for vulnerabilities disclosed after the date. For a production estate, the practical consequence is not an outage, it is an unbounded remediation obligation. Any defect that surfaces on October 2 becomes the organization's own problem to diagnose, patch, retest, and document, with no vendor backstop and no vendor-authored fix.

The exposure baseline then asks a narrower and more uncomfortable question. For each environment in the estate, what is the highest-consequence failure mode that the support entitlement currently mitigates? For a payroll-adjacent labor interface it is a defect in timesheet posting during a pay period. For a regulated asset register it is a data integrity defect discovered during an audit. For a safety-critical inspection workflow it is a defect in the workflow engine that blocks inspection recording. The point of the baseline is not to enumerate every possible defect. It is to identify the two or three environments where an unbounded remediation obligation is not survivable, and to place those environments at the top of every subsequent decision in this runbook.

Finish the day by inventorying the things that are almost never inventoried. Maximo's file-based integration layer traffic runs over middleware that is frequently outside the Maximo change board entirely, including IBM MQ deployments whose Managed File Transfer agent carries flat-file imports, bulk staging, and external-system handoff. If nobody on the 7.6.1.x upgrade team owns that middleware, nobody is patching it, and a vulnerability disclosed against it in mid-September will sit unremediated through a release freeze that was scoped to the Maximo application rather than the platform underneath it. Record the middleware versions, record who owns them, and treat that record as a Day One output, not a Day Five follow-up.

The day closes with three artifacts: an entitlement statement written in plain language for the change board, a ranked exposure list restricted to the environments where failure is not survivable, and a middleware ownership map. None of these require anyone to make a decision. All three are inputs to the decisions that begin on Tuesday.

Day Two: Triage by Environment, Not by Preference

Tuesday September 22 is decision day, and the decision most estates make badly is to treat the upgrade as a single program with a single finish line. The workable framing is a portfolio: an estate is a set of environments with different consequence profiles, and each one gets assigned to exactly one disposition before the week ends.

Four dispositions cover nearly every real case. The first is accelerate, which means a production cutover is genuinely reachable inside the window and the remaining work is execution rather than discovery. The second is formal interim support, where the organization contracts for sustained vendor support past the deadline. The third is compensating controls with documented risk acceptance, where the estate stays on 7.6.1.x with specific, named, tested controls and a signed acceptance of the residual risk. The fourth is triage, where environments are sorted into which of the first three postures each one receives.

Accelerate deserves the most skepticism, because it is the disposition organizations choose for reputational reasons rather than engineering ones. A 7.6.1.x estate is a candidate for accelerate only if the target architecture is already built, the identity provider configuration is already tested against the target platform, the customizations have already been assessed and either carried forward or formally abandoned, and a full cutover has already been rehearsed once end to end. If any of those four is still open on Tuesday, the estate is not accelerating, it is starting a project with five days left.

The hybrid path that emerged from the migration tooling discussions through 2026 is the more realistic version of accelerate, and it is worth stating plainly. The hybrid path migrates core asset and work management quickly and deliberately leaves low-value customizations behind, on the reasoning that a smaller target surface cutover faster beats a faithful port that never finishes. For an estate that has already done the customization assessment, this can compress scope enough to make the window real. For an estate that has not done the assessment, the assessment itself consumes the week.

Formal interim support carries an economics problem that should be priced on Tuesday rather than discovered in October. Sustained vendor support past the deadline exists, and it is premium priced, and it functions as a bridge rather than a destination. The number to establish is the annualized cost of the bridge against the fully loaded cost of the migration, not against zero, because the migration has to happen anyway. Estates that price the bridge against zero will approve it and then stall for a second year.

Compensating controls deserve more precision than they usually receive. A compensating control is not a promise to be careful. It is a specific, testable measure that reduces a specific, named risk. For an unsupported 7.6.1.x estate, the controls that carry real weight are hardened perimeter and network segmentation around the Maximo application tier, strict change control that freezes production customization, an accelerated patch posture for the middleware and runtime underneath Maximo, tested and restore-verified backups, and encryption posture validated end to end. Each one is a control with an owner and a test date. The risk acceptance that accompanies them is a signature from someone with the authority to carry the consequence, and that signature should be obtained in September, not in the audit that asks about it in March.

Close Tuesday with every environment assigned to exactly one disposition, each assignment carrying a named owner and a decision date. Environments without an owner are the ones that end up in October still undecided.

Day Three: The Full-Scale Rehearsal

Wednesday September 23 is the gate that separates a real cutover from an optimistic one, and it is the day most likely to be sacrificed to a status meeting. A cutover that has not been executed end to end against production-shape data is not a rehearsed cutover, and the difference between the two is measured in hours of unplanned downtime on the night it matters.

The rehearsal bar that the IBM community consistently recommends is specific, and it is worth restating because it is routinely softened in internal planning. Tested backups. Encryption posture validated. Cutover runbooks executed rather than read. Performance validation at one hundred to one hundred fifty percent of peak load. That last item is the one most frequently skipped and the one most frequently responsible for a cutover that completes successfully on Friday night and fails at scale on Monday morning. Load validation means driving the target environment above the highest concurrent load the source environment has historically seen, not at average load, and confirming that the response characteristics hold.

A production-shape rehearsal requires production-shape data, which means either a masked copy of production or a synthetic dataset that matches production in volume, distribution, and referential complexity. Estimates built on a ten thousand row extract tell you nothing about an environment that carries millions of work order history rows with hierarchy relationships across the asset register. If the masked copy is the blocker on Wednesday, that finding is itself the day's most valuable output, because it establishes that the cutover cannot be rehearsed inside the window and therefore that the estate belongs in the triage or interim-support disposition rather than the accelerate one.

The rehearsal should also exercise the integration boundary, because integration is where cutovers fail least visibly. Execute the file-based interfaces end to end and confirm that inbound files land, transform, and post, and that outbound extracts are generated and consumed downstream. Confirm that the middleware carrying that traffic is patched and that its version is recorded. Confirm that identity propagation behaves as expected when a user session crosses from the new application tier to the data layer, which is the failure mode that produces correct-looking screens with incorrect authorization behind them.

Finally, rehearse the rollback. A cutover plan without a rollback plan is a cutover plan with one branch removed. The rollback needs a trigger condition that is agreed in advance, an owner empowered to call it, and a time box beyond which rollback is no longer viable because too much production transaction volume has accumulated on the new system. The time box is the number nobody wants to compute, and it is the number that determines whether a bad cutover costs a weekend or a quarter.

If all gates pass on Wednesday, Thursday becomes a go or no-go review. If any gate fails, the correct Thursday action is reclassification, not heroics.

Day Four: The Go or No-Go Gate and the Interim Support Fallback

Thursday September 24 is the last day a major decision can be made and still be executed by people who are at work. The go or no-go gate should be a structured review with pre-agreed criteria rather than a conversation that arrives at a feeling, because a decision made on Thursday under production pressure is a decision that will be revisited at two in the morning on the night of the cutover.

Five criteria define a defensible go. The rehearsal has been executed end to end and passed, including rollback. The identity provider configuration has been validated against the target platform with real user populations. The customizations have been assessed, with carried-forward items tested and abandoned items documented. Performance validation has met the load bar. And the business owners of the affected processes have confirmed the acceptance window, including the downtime tolerance and the acceptable degradation during stabilization.

A no-go on Thursday is not a failure, and it should not be presented as one. A no-go on Thursday with a decision record, a documented risk position, and a contracted support posture is a materially stronger position than a go that produces a mid-October emergency. The distinguishing artifact between the two is documentation, and it should be produced on Thursday while the reasoning is fresh.

The interim support fallback needs three things configured this week rather than discussed this week. The first is the scope of the support arrangement itself, in writing, covering which environments are in scope and which severity classes are covered. The second is the compensating-control set for environments inside the arrangement, with control owners and first test dates, because a support contract does not reduce technical risk, it reduces response latency. The third is the migration plan for the period after the deadline, with dates rather than intentions, because the bridge has to end. Estates that leave the post-deadline plan as a quarter-level intention will still have it as an intention in the following year.

One detail that consistently gets missed: the security bulletin language IBM publishes on affected product versions is usually careful to state that listing only supported versions is not a statement that unsupported versions are unaffected. That language matters directly to a 7.6.1.x estate during its bridge period. Remaining unsupported does not mean remaining unexposed, and a five-CVE Manage bulletin issued in late August that names remediation versions on the supported release lines is telling the reader something about defect classes that may well exist in older code paths. Compensating controls should be sized with that in mind.

Day Five and the Short Week: Evidence, Handoff, and Freeze Discipline

Friday September 25 is for evidence and handoff, and it is the day that determines how the following week is spent. The following Monday through Wednesday is a three-day week that will be dominated by approvals and by whatever emergencies accumulated during the week that just ended. Anything requiring more than a signature on September 28 through 30 is effectively a Thursday problem, which means Friday is the last day to convert decisions into documents.

The evidence package should contain four things. The rehearsal record, including pass and fail conditions and the load numbers achieved. The rollback plan with the trigger condition and the time box. The risk acceptance signatures for every environment not migrating, with the specific named risk each signature accepts. And the migration plan for the bridge period with dates. Assembled on Friday, these four documents answer the question that arrives in the following quarter, which is why the estate is where it is. Assembled in October, they are reconstruction.

Freeze discipline is the other Friday obligation. The moment the disposition is decided, the 7.6.1.x environments not migrating should enter a change freeze on customization. Every customization applied to an unsupported production environment after September 30 is a customization that will be carried into the migration at its most expensive stage, and every one of them increases the surface that has to be revalidated. The freeze is cheap on Friday and expensive to impose in November, when the first urgent business request arrives and nobody remembers why the freeze exists.

Handoff matters for a reason that is organizational rather than technical. The people who spent the last five working days inside the cutover mechanics are the only people who currently hold the full picture, and they will be reabsorbed into project queues within a fortnight. A written handoff with named owners, current status, and the next three dates per environment keeps the position intact.

One closing note on the short week. Do not schedule anything on September 28 through 30 that depends on participation from a finance function, a vendor account team, or an executive approver who is also closing a quarter. The calendar is empty of rehearsal value, and treating it as contingency time is how a defensible position erodes into an undecided one.

Practical Implications

Three practical implications follow from treating this week as a gate sequence rather than a push.

First, the value of the week is measured in evidence, not in progress. An estate that enters October with an unchanged 7.6.1.x platform, a completed end-to-end rehearsal, a signed risk acceptance, a contracted support posture, and a dated migration plan is in a fundamentally different position from an estate with the same platform and no documents. The second estate has the same technology risk and none of the institutional cover. Organizations that spend the week on execution without producing artifacts will have the harder conversation.

Second, the middleware underneath Maximo belongs inside the upgrade scope from here onward. File-based integration traffic moves across messaging middleware that is rarely owned by the Maximo team and rarely covered by a Maximo-scoped freeze. That gap is a standing exposure, not a September one, and the fix is a version inventory with an assigned owner. Any estate that has never answered the question of who patches the messaging layer under its EAM interfaces should answer it this week, while the question is already on the change board.

Third, the migration decision does not end on September 30, and planning that assumes it does will slip. Sustained support past the deadline is a bridge with premium economics and a widening functional gap against the current platform generation. The functional gap is the part that compounds: the current release line carries capabilities in agentic assistance, condition monitoring, continuous delivery, and mobile that have no equivalent on 7.6.1.x, and every month on the bridge widens that distance. Estates should sequence the bridge so that the migration program has dates before the bridge begins, not after.

Bottom Line

Extended support for Maximo 7.6.1.x ends on September 30, 2026, and five full working days remain to establish a defensible position. The correct use of those days is a sequence of gates: baseline entitlement and exposure on Monday, assign every environment to a disposition on Tuesday, execute a production-shape rehearsal with load validation and rollback on Wednesday, run a structured go or no-go review on Thursday, and assemble the evidence package with a dated migration plan on Friday. Estates that can genuinely land a production cutover will know that by Wednesday evening. Estates that cannot will leave the week with three documents, a signed risk acceptance, and a support posture that survives an audit rather than with an unbounded remediation obligation and no record of why. The platform will keep running past October 1. What changes is who is responsible when something breaks.