Every IBM Planning Analytics practitioner has had some version of this conversation lately: someone (a colleague, an account rep, a slide in an IBM deck) asks whether you're “ready for v12.” It's usually asked the way you'd ask if someone has started their holiday shopping: casually, like there's an obviously right answer, and like everyone else has already given theirs.

IBM Is Already Moving

Start with the plain fact underneath all of this: IBM's own direction is unambiguous. The IBM Planning Analytics v12 platform and beyond is the strategic and technological direction for cloud hosted and managed by IBM. The earlier generation of IBM Planning Analytics on IBM Cloud isn't being switched off overnight, but it's also not where the investment is going. If your environment lives there today, the runway isn't infinite, and it's shortening rather than lengthening.

None of this is really new information. Anyone who's been paying attention to IBM's product direction over the last couple of years has seen where things are headed. What's changed is the urgency. Conversations that used to start with “someday” now start with “when”, and partners across the ecosystem, us included, are having a lot more of them. That shift in tone alone is worth noticing, because it tends to arrive before a shift in deadlines.

So, Where Do You Actually Stand?

Here's where most “are we ready” conversations go wrong: they jump straight to the destination without ever pinning down the starting point. But you can't plan a route you haven't mapped, and a IBM Planning Analytics environment is rarely as simple as “one server running some cubes.”

Take an honest inventory, not a full technical audit. Do a gut-check across a handful of dimensions:

• How many models are you actually running, and are they lean, focused applications, or has one grown over the years to quietly hold finance, sales, HR and manufacturing all at once, sharing dimensions because it once felt convenient?
• Who's really using it, and how? A population of mostly read-only report consumers is a very different starting point from one with dozens of contributors submitting into a monthly approval workflow.
• What does your front-end footprint look like? If your modelers are still living in Architect and Perspectives, or your casual users are opening classic TM1 Web sheets, that's a bigger piece of this journey than the cubes themselves will ever be.
• How entangled is your integration layer? Every file exchange, database connection, and scheduled script quietly moving data in and out of your environment must be accounted for, not just assumed to keep working.
• What does your data processing calendar actually look like not the published one, but the one your last two years of actuals show? Make note of when business processes actually take place and where there is overlap during the year.
• Who owns operations, and how formal is it? Undocumented environments that rely on individual team members institutional knowledge carry a different kind of risk than ones with a documented, repeatable promotion process.

None of these questions has an absolutely correct answer. A small, focused environment with a handful of users isn't behind, it's simply starting from a different point than an enterprise estate running a dozen models across regions with custom automation stitched through all of it. What matters is answering honestly, because the shape of your environment (not the number of cubes in it) is what actually determines how big this undertaking is, and where the effort will go.

A few answers, though, tend to change that shape on their own, regardless of how modest everything else looks. A workflow-heavy budget cycle, a stack of custom automations held together with scripts, or a genuine high availability requirement will each push a migration toward the more involved and technical end of the spectrum. It's worth knowing early which of those apply to you, rather than finding out midway through a plan built without them in mind.

Getting Ready Doesn't Mean Guessing

A few things are worth doing regardless of your timeline:

1. Run a structured discovery before you commit to a plan.
2. Run a partial migration that turns assumptions into an actual inventory:

• Which workbooks are really in use.
• Which integrations touch the outside world.
• What your security model quietly depends on.

It is far cheaper to find a surprise during discovery than during user acceptance testing.

1. Decide your deployment target deliberately, rather than by default. Where IBM Planning Analytics v12 runs (fully managed by IBM or self-managed on infrastructure you control) is a real decision with real consequences for cost, control, and how much operational burden lands on your own team. It deserves an actual conversation, not an assumption carried over from how things happen to work today.
2. Get honest about your calendar. If your planning cycles genuinely don't overlap that opens options that aren't available to an environment running at capacity year-round. If they do overlap, better to know that now than discover it mid-project.
3. Start the conversations with the longest lead times first; identity and network connectivity almost always sit outside the Planning Analytics team's direct control, and they queue behind other people's priorities.

It's also worth asking a the question: could your team actually operate the environment with proper update cadences, notifications, backups, and change control?  Many times these tasks are outside of a business owner’s comfort zone and can take time away from core job functions.

What You Gain and What Is Missing

On the gain side, IBM Planning Analytics v12 and beyond removes a surprising amount of the operational overhead that IBM Planning Analytics teams have simply learned to live with. Version upgrades happen with zero downtime and no support ticket required. You can update a single database instead of taking down an entire environment to patch one piece of it. The daily ritual of planning around a save process goes away. Backups guarantee a consistent state of the model, rather than racing a save before capturing files. Integrations get a genuinely better replacement for old command-line-style automation, in the form of native HTTP requests, and the platform picks up support for newer data formats as sources. Provisioning a new environment turns from a hardware-and-change-request conversation into something closer to self-service. None of this is flashy, and none of it will show up as a headline feature, but for anyone who has spent an on-call shift babysitting a save window it's the kind of change that actually matters day to day.

On missing side, be honest with yourself about what's not in the current IBM Planning Analytics v12 environment. If your modelers still live in Architect or Perspectives, or your casual users open classic TM1 Web sheets, those tools are fully deprecated in IBM Planning Analytics v12 and beyond. That's a retraining and rebuilding exercise, not a footnote. IBM Planning Analytics Workspace effectively replaces the legacy tools and adds additional functionality and a better user experience than the old IBM Planning Analytics v11 tools. If high availability matters to you budget for it honestly: replicating a database can roughly double the memory it needs. It's a real cost, not a hidden one, and it's exactly the kind of thing worth solving for before you migrate rather than after, which is exactly what our next post digs into.

The point isn't that the trade is a bad one. For most organizations we've talked with, it's a good one. The point is that it's an actual trade, and going in with your eyes open is what separates a migration that lands on schedule from one that discovers its real scope halfway through.

You Don't Have to Navigate This Alone

We hope that reading through those questions leaves you with a clearer sense of where you stand with v12. If it also left you with a slightly longer list of things you hadn't quite pinned down, that's normal too. Every organization running IBM Planning Analytics today is somewhere on this journey, and very few are exactly where they assumed.

Cubewise has helped many organizations work through this journey. But more useful than the track record is what it's built: real discovery frameworks and a sizing approach that make that first, hardest step (figuring out where you stand) fast and evidence-based, rather than a guessing exercise.

In our next post, we get into the practical work you can start today, in your current IBM Planning Analytics v11 environment, to make the eventual move to IBM Planning Analytics v12 more affordable and less disruptive, regardless of when you cut over. If this post was about finding your position on the map, that one is about the first leg of the route.

If this topic is of interest to you, I encourage you to join me and the Cubewise team at IBM TechXchange 2026.