Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
If your agency is still running IBM Planning Analytics 2.0.9.x, your support has either already lapsed or expires on 31 October 2026.
For most Australian government finance teams, the months leading up to that date are also the quietest stretch of the year. Year-end close is behind you and budget preparation has not yet taken hold.
This article sets out how to use that window.
When a version reaches end of support, IBM stops issuing security patches and fixes. For an agency running budget data through the platform, that is a security risk and an audit exposure at the same time.
Any agency still on 2.0.9.x or earlier is running unsupported software today. If a vulnerability is found, no patch is coming.
That invites reasonable questions from auditors and risk committees. How is a critical system being maintained? Is continuity of the planning function assured? Answer those with a plan already in motion.
Plenty of organisations have made this move without drama. The difficulty comes from leaving it late.
Support for 2.0.9.x and earlier ended on 31 October 2025.
Extended support, which is a separate purchase, runs to 31 October 2026. If your agency bought it, you have cover until then.
The current supported release is the 2.1.x series, which IBM supports through to 30 April 2027.
Note that second date when you plan. Moving to 2.1.x returns you to supported ground, but only until April 2027. IBM works to roughly a three-year general support lifecycle, so factor the step after this one into the plan.
The most direct route back to supported ground. You stay inside the Planning Analytics 2.x family on a familiar architecture, and you receive security patches again.
It suits teams who want to clear the support exposure cleanly without absorbing a larger platform change at the same time. Factor the April 2027 horizon into the plan.
The cloud-hosted service takes the platform off your own servers, and suits agencies whose IT strategy is already heading toward managed services.
In government it has to sit inside your data residency, security, and procurement requirements. Assess it against those before treating it as a technical decision.
The newest generation, and a real step forward. It is also not a like-for-like upgrade, which is worth understanding before you commit.
It is tempting to treat a version change as install-the-new-one-and-carry-on. With v12 that will get you into trouble.
Administration works differently. So does file handling, and so does the way objects get promoted between environments, for example, moving a change from development through to production.
These touch the operational routines your team uses to keep the system running and to make changes safely. Plan, test, and roll out v12 with the care you would give any significant system change, and resource it accordingly.
No. Your TM1 data model, your planning logic, and your reports all carry forward, along with the accumulated understanding of how your agency plans and budgets.
TM1 Architect, TM1 Perspectives, TM1 Applications, and Performance Modeler are not included in 2.1.x. If your team still uses any of them, part of the transition is moving to Planning Analytics Workspace and Planning Analytics for Excel.
That is a change in the tools your team uses, not a loss of the model underneath. Excel stays central, so the ways of working your team knows move onto current interfaces.
Work out now which legacy tools are still in daily use. It tells you the real shape of the work ahead.
Testing and cutover should land in quiet months, never during budget preparation or year-end.
Your planning environment is under the most load during budget preparation and year-end. Those are the worst weeks to be validating a new version, retraining users on Workspace or Planning Analytics for Excel, or working through the small issues that surface in any transition.
For most agencies the usable window closes when budget preparation starts, which is also close to when extended support lapses.
Confirm when your quiet period actually ends. Agencies vary. Your planning calendar decides this, not the support date.
Leave room for testing inside it. Parallel running and user validation take time. Compressing them against a deadline is how upgrades go wrong.
Sequence the tool migration with the upgrade. If you are moving off legacy tools, the shift to Workspace and Planning Analytics for Excel belongs on the same timeline, with training away from peak periods.
Decide early whether the window is big enough. If it is not, plan for a documented gap instead of a compressed timeline.
Some agencies will not make it.
The exposure is manageable, but it has to be documented rather than ignored. Auditors and risk committees respond very differently to a known gap with a dated remediation plan than to a system nobody has looked at.
Have in writing the date your support lapses, and the plan and timeline that closes it. Record the compensating controls you are running in the meantime, such as restricted network exposure and tightened access.
Talk to IBM or your partner about your options before the date rather than after.
And if the choice is between running unsupported for a few extra months or forcing a cutover into budget preparation, take the first. A documented gap is a smaller risk than a failed transition during the weeks your agency depends on the system most.
Confirm which version you are running. Check whether you hold extended support and to what date. List any legacy tools still in daily use. Work out when your quiet window opens and closes.
That costs almost nothing, and it tells you whether you are choosing your timetable or reacting to one.
From there, the choice between 2.1.x, the cloud service, and a v12 transition can be weighed against your agency's circumstances.
The capability your team has built is preserved either way. Planning early just means doing the work in a month you choose, with an audit position you can defend while you do it.