PowerCenter End of Support: 4 Migration Paths for Enterprise Data Teams
The deadline everyone was planning around has already passed. Informatica PowerCenter 10.5.x standard support ended on 31 March 2026. If PowerCenter is still running production pipelines anywhere in an organisation, every day since that date has been spent on a platform that receives no new features, no fixes for newly discovered vulnerabilities, and no systemic improvements of any kind.
Extended support is available through 31 March 2027, with sustaining support stretching to 2029. That sounds like breathing room. It is not a strategy, and it is worth saying plainly: a holding pattern still burns fuel, it just delays the moment you notice the tank is empty.
There is a second factor now sitting on top of the deadline, and it changes the calculus for one of the four paths below. Salesforce completed its $8 billion acquisition of Informatica in November 2025. Salesforce's own stated priority for that acquisition is feeding data into its Agentforce AI platform, not maintaining PowerCenter's legacy customer base. Anyone weighing whether to stay inside the Informatica ecosystem is no longer just betting on Informatica's roadmap. They are betting on how a CRM company prioritises a data-integration product it acquired for a different reason entirely.
The real question for IT leaders right now is not whether to move off PowerCenter. It is how. Four paths exist, and three of them cost more than they first appear to.
Executive Summary: The Four Paths at a Glance
- Extended support buys time, not safety. It is a legitimate six-to-twelve month bridge while a migration is scoped, and an expensive permanent home if treated as anything longer.
- IDMC keeps you inside Informatica, but billing becomes unpredictable. Consumption-based IPU pricing scales with data volume and job complexity in ways that routinely exceed what finance teams budgeted for, a risk that has grown since Informatica's ownership changed hands.
- Lift-and-shift looks cheap and usually isn't. Regex-based code conversion preserves syntax, not meaning, and organisations that take this path frequently pay for a second clean-up project within 12 to 18 months.
- Modernising during migration is the only path that fixes the underlying problem, not just the deadline. Converting logic natively into the target platform, while cleaning up technical debt in the same motion, delivers measurably lower cost and fewer post-migration incidents than any of the other three.
Why "Just Renew Extended Support" Is Not a Plan
Extended support keeps the lights on. It does not reduce risk, and it does not reduce cost. It defers both while charging a premium for the privilege.
Here is what that premium actually buys: continued access to Informatica's support desk, and fixes for the most critical issues only. It does not buy new features, broad bug fixes, or protection against the technical debt that has been accumulating in every PowerCenter environment for years. Talent scarcity compounds the problem directly. PowerCenter-certified engineers are retiring from the workforce faster than new ones are being trained on a platform Informatica has not actively sold since 2023, so the cost of keeping the platform running rises even as the platform itself stays frozen in place.
Extended support has one genuine use case: teams that need six to twelve months of runway to plan a proper migration, not teams looking for a permanent home. Stretched beyond a bridge, it becomes the most expensive option on this list, because every pound spent on it is a pound spent standing still.
Path 1: Pay for Extended Support
What it is: Renew Informatica's paid extended support tier through 31 March 2027, then sustaining support after that.
What it doesn't fix: The underlying technical debt keeps compounding. Pipelines built a decade ago on assumptions that no longer hold, data volumes, compliance requirements, and business logic that has since changed hands three times, stay exactly as fragile as they were the day before the deadline. Meanwhile, the pool of engineers who can safely touch PowerCenter keeps shrinking, and extended-support pricing tends to rise the following year rather than fall.
In practice: extended support makes sense as a deliberate bridge with a fixed end date and a migration plan already under way behind it. It does not make sense as the plan itself.
Path 2: Upgrade to Informatica IDMC
What it is: Move from PowerCenter to Informatica's cloud-native Intelligent Data Management Cloud, staying inside the Informatica ecosystem, now owned by Salesforce.
Why it's tempting: Same vendor relationship, broadly the same skill set, no need to rebuild business logic on an unfamiliar engine. For teams comfortable with Informatica as a company and mainly needing to get current, this reads as the path of least resistance.
Where it gets expensive: IDMC bills on a consumption-based model using Informatica Processing Units, or IPUs. Unlike a fixed licence, IPU costs scale with data volume, job complexity, and usage patterns, and that scaling is not always transparent up front. Finance teams that budgeted for a predictable annual licence often find IPU consumption exceeding projections once real production workloads move over, particularly as data volumes grow year on year. Renewal quotes landing higher than expected has become common enough that it now shows up regularly in procurement conversations across mid-market and enterprise teams alike.
In practice: IDMC is a legitimate choice for organisations committed to staying inside the Informatica ecosystem long term, willing to build cost governance around variable IPU billing, and comfortable that ecosystem now sits inside Salesforce's own product priorities rather than an independent data-integration vendor's. It is a weaker option for anyone hoping to escape unpredictable spend, since it trades a known problem, ageing software, for a less visible one, unpredictable metering under new ownership.
Path 3: Lift-and-Shift Into a New Platform As Is
What it is: Take existing PowerCenter workflows and port them, largely unchanged, onto a new target platform, Databricks, Snowflake, or Microsoft Fabric, using automated or semi-automated code conversion.
Why it's tempting: It looks like the fast, cheap option on a project timeline. Convert the code, point it at the new platform, declare the project finished.
Why it fails more often than it succeeds:
- Technical debt moves with the code. Lift-and-shift does not clean anything up. It relocates the same inefficient logic, the same brittle dependencies, and the same undocumented workarounds onto more expensive infrastructure. The problems that made PowerCenter hard to maintain do not disappear. They simply get a cloud bill attached to them.
- Logic breaks silently. PowerCenter's proprietary constructs do not map one-to-one onto Spark or SQL dialects on the target platform. Text-based and regex-driven conversion tools translate syntax without fully preserving what that syntax actually means. A transformation that behaves one way in PowerCenter can behave subtly differently once rewritten, and those discrepancies often surface only after go-live, when a report is quietly wrong for weeks before anyone notices.
- No genuine improvement happens. The same inefficiencies present in the legacy environment get faithfully reproduced in the new one, since the goal of lift-and-shift is fidelity to the old code, not improvement of it.
- Vendor lock-in gets built into the migration itself. Many free or low-cost conversion tools are built for a single target platform. Choosing one commits an organisation to that platform before alternatives have been properly evaluated.
Enterprises that take this route frequently end up funding a second clean-up project within 12 to 18 months, which means the cheap option quietly becomes the most expensive one once its true cost is added up.
Path 4: Modernise During Migration
What it is: Convert PowerCenter workflows natively into the target platform's own constructs, Databricks Delta Live Tables and PySpark, Snowflake SQL and Snowpipe, or Microsoft Fabric and OneLake, while standardising and improving the underlying logic in the same motion, rather than as a separate project afterwards.
Why this is structurally different from lift-and-shift: The distinction comes down to how the conversion actually happens. A genuine migration platform parses PowerCenter workflows into an Abstract Syntax Tree, a structured representation of what the logic means, not just what the code says, and maps that meaning onto a dialect-agnostic canonical model before generating native code for the target. That is a fundamentally different operation from regex or text substitution, because it preserves business intent through the conversion instead of only preserving syntax.
This is the approach DataVolve is built around. Rather than treating migration as a one-time code-conversion exercise, DataVolve's AST-based canonical model discovers the existing PowerCenter estate, jobs, dependencies, schedules, and complexity, and regenerates it as native pipelines on the chosen target, applying Medallion architecture (Bronze, Silver, Gold) and resolving dialect-specific technical debt along the way rather than carrying it forward. Job schedulers such as Control-M, AutoSys, and Tidal, which most conversion tools ignore entirely, get migrated to native orchestration as part of the same process, alongside automated source-to-target reconciliation confirming parity before cutover.
In practice: engagements built on this approach have delivered roughly 40% lower migration cost, 60 to 70% faster pipeline delivery, and around 75% fewer post-migration incidents compared with traditional lift-and-shift programmes, with first-year ROI in the 75 to 100% range. Those figures are conservative estimates drawn from client engagements, not vendor projections, and should still be validated against your own landscape before they anchor a budget.
Decision Framework: Which Path Fits Your Situation
| Priority | Extended Support | IDMC Upgrade | Lift-and-Shift | Modernise During Migration |
|---|---|---|---|---|
| Timeline pressure is severe (need a bridge now) | Fits, as a short bridge only | Moderate fit, longer rollout | Fast but risky | Fastest safe path, via a bounded pilot |
| Architecture ambition is low (just stay current) | Doesn't address it | Best fit if staying with Informatica | Doesn't improve architecture | Overkill if there's genuinely no ambition |
| Architecture ambition is high (modern lakehouse or warehouse) | Poor fit | Partial fit, still Informatica-bound | Undermines the goal | Best fit, architecture improves as part of migration |
| Budget favours predictable cost | Predictable short term, rising over time | Unpredictable, IPU billing scales with volume | Appears cheap upfront, expensive in clean-up later | Higher upfront investment, lower total cost of ownership |
| Budget favours lowest total cost of ownership | Weak, cost compounds with risk | Weak to moderate, depends on usage discipline | Weak, hidden second-project cost | Strong, cost and rework both drop |
| Team wants vendor flexibility for future targets | Not applicable, staying on an existing platform | Locked into Informatica | Often locked to one target platform | Platform-agnostic across Databricks, Snowflake, Fabric, BigQuery |
Most organisations land on a mix: a short, deliberate stretch of extended support while a modernisation programme is scoped, followed by a direct move to Path 4 rather than a detour through lift-and-shift.
How a Bounded Pilot Removes the Guesswork
The hesitation with any migration decision usually is not the destination. It is the fear of a multi-year commitment made on incomplete information. A Vector Sprint solves that by design: a four-to-six week discovery engagement that inventories the existing PowerCenter estate, assesses migration complexity, finalises target architecture, and ends in an explicit go or no-go decision before anyone commits to the full programme.
Inside that window, a first pilot wave, typically four to eight real entities converted in one to two weeks, produces a concrete, working proof point rather than a slide deck of projections. Teams see actual converted pipelines, actual reconciliation results, and an actual complexity assessment before deciding whether to proceed, expand scope, or step back. That structure turns a high-stakes platform decision into a series of small, reversible steps rather than one large commitment made under deadline pressure.
The Bottom Line
Standard support for PowerCenter 10.5.x is over. Extended support buys time but not safety. IDMC keeps organisations inside the Informatica ecosystem at the cost of billing predictability, now under Salesforce's ownership rather than an independent vendor's. Lift-and-shift trades a fast timeline for a second clean-up project later. Modernising during migration, converting logic natively into the target platform while fixing technical debt in the same motion, is the only path that addresses the deadline and the underlying problem at the same time. A bounded discovery sprint remains the lowest-risk way to find out which path fits, before a programme budget commits to any of them.
Frequently Asked Questions
What are the options after Informatica PowerCenter end of support?
Four realistic paths exist. Pay for extended support through 31 March 2027 as a short-term bridge. Upgrade to Informatica's IDMC and stay inside the Informatica ecosystem, now owned by Salesforce. Lift-and-shift existing workflows onto a new platform largely unchanged. Or modernise during migration, converting logic natively into the target platform's own constructs while resolving technical debt in the same process. Of the four, only the last one addresses both the support deadline and the accumulated technical debt at the same time; the other three either delay the decision or relocate the problem onto new infrastructure.
Should we upgrade from PowerCenter to Informatica IDMC?
It depends on what the organisation actually wants from the move. IDMC is a reasonable choice for teams committed to staying with Informatica long term and prepared to govern variable IPU-based billing carefully, since consumption costs scale with data volume and job complexity rather than sitting on a fixed licence. It is a weaker choice for anyone hoping to escape unpredictable spend, and worth factoring in that Informatica's product roadmap now sits inside Salesforce, a company that acquired it primarily to strengthen its own Agentforce AI platform rather than to prioritise PowerCenter's legacy customer base specifically.
What is the difference between lift-and-shift and PowerCenter modernisation?
Lift-and-shift converts PowerCenter code into a new platform's syntax while leaving the underlying logic, inefficiencies, and technical debt untouched, typically using regex or text-substitution tools that preserve syntax without fully preserving what that syntax actually means. Modernisation during migration parses the same workflows into an Abstract Syntax Tree, a structured representation of the logic's actual intent, then regenerates that logic as clean, native code on the target platform. The practical difference shows up after go-live: lift-and-shift projects frequently need a second clean-up effort within 12 to 18 months, while modernisation resolves the debt as part of the original migration.
Can PowerCenter workflows be migrated directly to Databricks, Snowflake, or Microsoft Fabric?
Yes, through either path, but the outcome differs meaningfully. A direct, largely automated conversion is possible with both lift-and-shift tools and native modernisation platforms. The difference is what lands on the target: lift-and-shift produces code that mimics PowerCenter's original logic, including its flaws, translated into the new platform's syntax. Native modernisation produces idiomatic code built for that platform specifically, Delta Live Tables and PySpark on Databricks, native SQL and Snowpipe on Snowflake, or Fabric and OneLake constructs on Microsoft Fabric, along with migrated job scheduling and automated reconciliation to confirm parity before cutover.
How can we assess PowerCenter migration complexity before committing to a full programme?
A bounded discovery engagement, rather than a full commitment made on assumptions. A four-to-six week Vector Sprint inventories the existing PowerCenter estate, assesses complexity across jobs, dependencies, and schedules, and finalises target architecture before any large-scale migration begins. Within that window, a first pilot wave, typically four to eight real entities converted in one to two weeks, gives a working proof point: real converted pipelines and real reconciliation results, rather than a projection. That evidence is what should determine whether to proceed, adjust scope, or reconsider the approach entirely, not a vendor estimate produced before any actual workload has been touched.
Tarento´s DataVolve is built specifically for an AST-based migration platform that converts PowerCenter workflows natively into Databricks, Snowflake, or Microsoft Fabric, resolving technical debt in the same motion rather than carrying it onto new infrastructure. Talk to us→
How AI Is Transforming Enterprise Learning Management Systems
