16 Days, One Business Week: The Maximo 7.6.1.x Sprint-Week Go/No-Go

Extended support for Maximo 7.6.1.x ends on September 30, 2026. That is sixteen days out, and it leaves exactly one full business week in front of the deadline. Whatever your organization is going to do, the window to do it deliberately is closing faster than most governance calendars can respond.

The countdown coverage in this niche has been relentless. Vendor-adjacent publishers have monetized the deadline for months, community megathreads have been running since the spring, and every week produces another post that leads with the number of days remaining. What almost none of that coverage does is answer the question the practitioner audience is actually sitting with right now: it is Monday of the final full business week, my migration is not finished, what do I do with the five days I have left.

This article is written for that reader specifically. It is not a decision tree for organizations that started planning in January. It is a sprint-week runbook for the three reader modes that exist with sixteen days remaining: teams trying to land before September 30, teams buying time through Sustained Support, and teams triaging scope down to the environment that actually matters. It also covers what happens to the instances left behind, because some will be, and the compensating controls those instances require on October 1 are an artifact an executive has to sign, not an email someone writes at 4:30 on a Friday.

One important framing note before the detail. By October 6, the decision is made whether or not it was made deliberately. Nothing in this article changes the deadline, and nothing here should be read as permission to rush a cutover that has not been rehearsed. The entire value of a sprint-week plan is that it forces an honest answer to a single question: can you land, and if not, what is your dated, documented position instead.

Mode A: Landing Before September 30 and the Five Gates That Decide It

If you are attempting to land on MAS before the deadline, the useful exercise is not to re-open the business case. That argument is settled. The useful exercise is to test five gates, and to test them with the same discipline you would apply to a production outage. Any red gate means you are gambling on go-live quality rather than landing, which is a materially different risk posture than most steering committees understand when they approve a compressed schedule.

Gate one: cutover rehearsal on production-like data. Not a sandbox, not a subset, not a partial restore from six months ago. A full rehearsal using a data volume and distribution that resembles production, executed end to end, with a measured duration. If the rehearsal has not happened, you do not have a schedule. You have a guess with dates attached. The rehearsal produces the only number that matters for the remaining week: how many hours the real cutover will take, and therefore how many hours of contingency you have before Monday morning.

Gate two: integrations tested end to end. The phrase "works in development" has ended more Maximo cutovers than any software defect. Interface testing must exercise the full path: the integration engine or middleware, the authentication, the payload transformation, the downstream system's response, and the error path. An integration that succeeds on the happy path and fails silently on a payload error is worse than an integration that is visibly broken, because the failure surfaces in a financial reconciliation three weeks later instead of in a test log. Verify every interface that touches inventory, purchasing, financial posting, GIS, or the data warehouse.

Gate three: performance validated at peak load. Run at 100 to 150 percent of peak concurrent usage, with a realistic mix of transactions rather than a synthetic uniform load. Maximo estates routinely discover that the new configuration behaves well at average load and degrades badly at the start of a shift, when hundreds of technicians open their mobile clients simultaneously. If you cannot load test, at minimum document the performance risk explicitly and name the person accepting it.

Gate four: rollback path documented and exercised. Documented is not enough. Exercised is the standard. If the rollback has never been run, you do not have a rollback, you have a document. The rehearsal in gate one is the natural place to exercise it, including the decision criteria that trigger it: what specific symptoms, observed by whom, within what window, cause the team to stop and revert.

Gate five: users trained on the new interface. Not a slide deck circulated by email. Actual hands-on exposure for the roles that transact daily: planners, schedulers, storekeepers, supervisors, and the technicians who live in mobile. The most common post-cutover productivity dip is not caused by broken functionality. It is caused by capable users who cannot find a familiar screen and default to phone calls, which silently converts transactional work into backlog.

The honest fallback. If one or more gates are red, the correct answer is usually a partial cutover rather than an all-or-nothing gamble. Stabilizing one high-value environment, typically a single site or a single business unit, proves the platform, the integrations, and the operating model under real load while the remaining environments stay on the legacy line. A partial landing that works is a strategic position. A botched full cutover is a recovery project that consumes the next two quarters and destroys the credibility needed for the second attempt.

Mode B: Bridging Through Sustained Support Without Lying to Yourself

A meaningful share of organizations will not land by September 30, and for many of them the correct decision is to buy time rather than compress a migration into a window it cannot survive. That option exists, it has a name, and it has a price and an expiry.

IBM's Sustained Support offering provides continued coverage beyond the end of extended support. The critical distinction, and the one most frequently blurred in hallway conversations, is between the availability of support and the delivery of change. Sustained Support is priced-and-dated coverage. It is not a patch stream, and it is not a development path. You are paying for the ability to raise problems and receive guidance on a product line that is no longer receiving functional enhancement. You are not buying new capabilities, and in many cases you are not buying the same defect-response posture you had during extended support.

Treat Sustained Support as a bridge with a visible expiry date, not a destination. The moment the decision is made to bridge, two artifacts should be produced. The first is a dated migration commitment with a target quarter and a named accountable executive, because a bridge without a completion date becomes a permanent operating state by default. The second is a cost model that compares the fully loaded bridge cost, including the annual coverage fee plus the accumulated integration and customization debt of staying on the legacy line, against the cost of accelerating the migration. Vendors and consultancies publish these numbers loosely; the only version that matters is the one built from your own license and labor data.

Practically, organizations that bridge successfully tend to do three things in the bridged period that organizations that bridge poorly do not. They freeze functional change on the legacy line, so the migration scope stops growing. They continue integration remediation work in parallel rather than pausing it, because integration debt is the long pole. And they run the migration program on a delivery cadence with dates, not as a background activity, because background activities in asset-intensive organizations are indistinguishable from cancelled activities.

There is also a licensing and governance dimension worth stating plainly. Bridging does not change your entitlement to use the software you have licensed. It changes your access to vendor remediation. In regulated environments, and especially in organizations with documented cybersecurity frameworks or contractual security obligations, the loss of vendor security response for newly discovered vulnerabilities in an unsupported version is the material risk, not the loss of enhancement.

Mode C: Triaging Scope Down to the Environment That Actually Matters

The third mode is scope reduction, and for multi-instance estates it is often the most rational path under a sixteen-day clock. Most large Maximo organizations do not run one environment. They run a production instance, a training instance, and a handful of departmental or regional instances that accumulated over a decade of acquisitions, reorganizations, and pilot projects. Treated as a portfolio, that inventory is an opportunity.

The triage discipline is straightforward. Rank every instance by exposure. Exposure is a function of three factors: business criticality if the instance stops functioning, network reachability from untrusted networks, and the sensitivity of the data the instance holds. Production instances serving revenue-generating operations rank highest. Departmental instances running read-only reporting for a small user population rank lowest, and are frequently candidates for retirement rather than migration.

Retirement is the underused lever. An instance whose scope can be absorbed into MAS at the target platform, or whose remaining users can be moved to a surviving instance, does not need its own migration. It needs a decommission plan. Every instance you retire removes a migration, a cutover rehearsal, a set of integrations, a training wave, and a permanent addition to your support surface. In a compressed window, retiring two low-criticality instances is often worth more than any amount of schedule compression on the instances that remain.

For the instances you choose to migrate, sequence by exposure rather than by convenience. Land the most exposed environment first, because it is the one whose continued operation on an unsupported line carries genuine enterprise risk. Land the least exposed environment last, or not at all in this cycle, and explicitly document that decision.

What triage must not become is an excuse to migrate nothing. The purpose of scope reduction is to make the achievable migration achievable with quality, not to convert a delivery commitment into a series of deferrals. Apply the same dated-commitment standard from Mode B to every deferred instance: a target quarter, an accountable owner, and a risk position signed at the right level.

The October 1 Compensating-Controls Package for Instances Left Behind

Some number of 7.6.1.x instances will still be running on October 1, and in most large estates that is a legitimate, defensible outcome provided the risk is controlled and documented. The mistake is treating "we are still on 7.6.1.x" as a status rather than an accepted risk that requires an artifact.

Four controls form the minimum defensible package.

Reduced network exposure. An unsupported instance should not be reachable from general corporate networks or the internet unless there is a specific, documented, business-justified exception. Restrict access to the smallest network segments that serve the remaining user population, remove or disable remote access paths that are no longer in active use, and close the administrative interfaces to a hardened management network. In many estates the largest reduction in risk on October 1 comes from removing exposure that nobody needed and nobody removed.

Essential named users only. Strip the user population to the people who genuinely require access to perform a documented function on that instance. Generic accounts, service accounts with interactive logins, dormant contractor accounts, and role memberships that accumulated over years are the standard findings in any access review, and every one of them is a path into a platform that will not receive vendor security fixes. Perform the review as an entitlement review with evidence, not as a cleanup exercise.

Hardened monitoring and alerting. An unsupported platform needs more visibility than a supported one, not less. Ensure that the instance is in scope for your security monitoring, that authentication anomalies and unexpected outbound traffic generate alerts, that backup success and integrity are verified rather than assumed, and that someone is accountable for responding. Documented detection is what distinguishes an accepted risk from an unmanaged one.

A dated risk-acceptance memo signed by the accountable executive. This is the artifact. Not an email, not a meeting minute, not a slide. A short document that names the instance, the version, the date the vendor entitlement changed, the business function it supports, the compensating controls in place, the migration commitment with its target date, and the named executive accepting the residual risk. The memo is what makes the position defensible in an audit, and it is what prevents an operational decision from silently becoming an unowned enterprise exposure.

A Day-by-Day Calendar for the Final Five Business Days

Sprint-week planning fails when it is expressed as a list of workstreams rather than a sequence of days. The following structure assumes a land-by-September-30 attempt and should be adjusted to the gates your rehearsal has actually cleared.

Monday. Complete or confirm the cutover rehearsal and produce the measured cutover duration. Convene the go/no-go review against the five gates. Confirm the environment inventory, including which instances are being migrated, bridged, or retired. Freeze functional change on all environments in scope.

Tuesday. Execute end-to-end interface testing on the remaining unproven integrations. Verify performance test results against peak load. Confirm the rollback procedure by walking the actual steps with the actual operators.

Wednesday. Resolve or formally accept every open defect from the rehearsal and the interface tests. Complete the access and entitlement review for any instance that will be left on the legacy line. Issue the risk-acceptance memo for executive signature.

Thursday. Confirm operational readiness: runbooks, on-call rosters, escalation paths, and the communications plan for users. Complete final user training for daily transactional roles. Confirm the backup and restore position for the target platform immediately prior to cutover.

Friday. Hold the final go/no-go with a named decision owner and a recorded decision. If the decision is go, execute the cutover window with the agreed rollback criteria in front of the team. If the decision is no-go, convert on the same day to Mode B or Mode C with the same dated-commitment standard, and do not let the window close with the decision undefined.

The point of sequencing by day is not ceremony. It is that a compressed migration's failure modes are almost always decision-timing failures rather than technical failures. Teams that compress a schedule and skip the rehearsal do not fail because the software cannot do the job. They fail because nobody forced the week to produce a decision.

Practical Implications

For platform owners and MAS architects, the sprint-week dynamic changes the nature of your job. You are no longer producing a strategy, you are producing evidence and decisions under time pressure, and the evidence has to be defensible after the fact. That means documentation discipline matters more in the next sixteen days than in the previous sixteen months. Every gate assessment, every accepted risk, and every deferred instance should exist as an artifact with a date and a name attached.

For EAM managers and functional leads, the practical implication is training and data readiness. The migration's functional risk concentrates in two places: users who cannot complete their daily transactions on the new interface, and data that arrives incomplete because the extraction and cleansing work was deferred. If your cleansing plan is not finished, prioritize it by what the reliability and work management functions require on day one rather than by what is technically convenient.

For IT directors and risk officers, the compensating-controls package is the deliverable that matters most if your organization is bridging or triaging. The controls themselves are not exotic. The failure mode is that they are discussed and never written down, which leaves the organization holding an exposure with no owner and no record of how the decision was reached. Ask for the memo. If the memo does not exist, the risk has not actually been accepted.

For decision makers who have been avoiding the topic, the useful reframe is that the deadline is a fact, not a risk. What remains discretionary is your posture on October 1: landed, bridged with a dated plan, triaged with an exposed environment prioritized, or running an unsupported platform with controls and an accepted risk. Three of those four are defensible. Drifting into the fourth without a decision is the only option that is not.

Bottom Line

Sixteen days and one full business week remain before Maximo 7.6.1.x extended support ends on September 30, 2026. If you are attempting to land, the five gates decide it: rehearsed cutover on production-like data, integrations tested end to end, performance validated at peak load, a rollback that has actually been exercised, and users trained on the interface they will use on Monday morning. Any red gate means a partial cutover that works beats a full cutover that does not.

If you are not landing, choose the bridge or the triage path deliberately and on Monday, not on the afternoon of September 30. Sustained Support is priced coverage with an expiry, not a patch stream and not a destination, so attach a dated migration commitment with a named executive the day you buy it. If you are reducing scope, retire the low-exposure instances outright and sequence the rest by exposure, because every retired instance removes a migration rather than deferring one.

And write down which instances you are leaving behind. Reduced network exposure, essential named users only, hardened monitoring, and a dated risk-acceptance memo with an executive signature. That memo is the difference between an accepted enterprise risk and an unowned exposure, and it is the only piece of this work that will be examined after the fact.