Migrate from Informatica PowerCenter to Apache Hop: what the work involves
Moving from PowerCenter to Apache Hop is a rebuild of mappings and workflows as Hop pipelines and workflows, not a conversion, and the effort scales with the size and complexity of your repository. Informatica announced that PowerCenter 10.4 support ended March 31, 2024, and that Extended Support is fee-based, so the first task is to confirm which PowerCenter version you run and what your contract covers. Hop's Kettle importer converts .ktr and .kjb files from Pentaho Data Integration, but it does not read PowerCenter objects, so no automatic importer will carry your mappings across. Plan for every mapping to be specified and rebuilt by hand, with testing against source and target data at each step.
Internal ETL engineers usually do this work, often with an implementation partner who brings Hop and orchestration experience and helps set up the environment. Start by using the pmrep ObjectExport XML files as the inventory, then sort mappings by business value, transformation complexity, source and target systems, and how often each one runs. Simple pass-through and filter mappings are usually quick to rebuild. Mappings with complex lookups, slowly changing dimension logic, custom Java or SQL transformations, or session-level overrides take longer, and their runtime behavior is not in the XML, so the team must recover it from existing job logs and business owners.
The main risks are behavioral drift, undocumented logic and connection handling. Parallel runs against the same inputs, with row counts and reconciliation checks, are the most direct way to catch differences before a cutover. Confirm with your team which Hop engine will run each pipeline (the native engine, Spark, Flink or another runtime) and check it against your data volumes and Java requirements, since Apache Hop 2.19.0 requires Java 21. Keep the existing PowerCenter environment available until the parallel runs are signed off, and document the decisions behind each rebuilt pipeline so auditors and future engineers can trace them.
Which PowerCenter capabilities map to Apache Hop and which need rework
This table compares the main PowerCenter building blocks with their Apache Hop counterparts and marks each as clean, needs rework or gap. Read it as a planning checklist: clean rows can usually be rebuilt directly, rework rows need design decisions, and gap rows need a substitute or a separate tool. The Kettle importer only converts Pentaho Data Integration content, so PowerCenter objects are rebuilt by hand from exports.
| PowerCenter capability | Apache Hop equivalent | Status and what to confirm |
|---|---|---|
| Mappings and transformations | Pipelines built from Hop transforms on the visual canvas | Clean for common transforms such as filter, join, lookup, aggregate and sorting. Confirm each transform's behavior against the PowerCenter source. |
| Workflows and sessions | Hop workflows that call pipelines, with actions for control flow | Needs rework. Session-level settings such as commit intervals, error handling and partitioning must be re-declared on each pipeline. |
| Worklets and reusable logic | Sub-workflows and parameterized pipelines | Needs rework. Confirm that parameters and return values map to the original reuse pattern. |
| Parameter files | Project and environment variables, plus pipeline parameters | Needs rework. Parameter names and scoping rarely carry over unchanged, so keep a mapping table from the pmrep exports. |
| Connections | Hop metadata objects for database and other connections | Needs rework. Passwords and credentials must be re-entered or sourced from a secrets store. The Kettle importer does not read PowerCenter connections. |
| Scheduling | No built-in scheduler in Hop Server; an external scheduler submits work | Gap. Choose and operate an external orchestrator such as cron, Airflow or another tool before cutover. |
| Repository and version control | Projects stored as files, typically in Git | Needs rework. Repository history stays in PowerCenter exports, so decide what history to keep in Git. |
| Execution engine | Native Hop engine, Hop Server, Apache Spark, Apache Flink or Databricks via runtime configuration | Clean for portability, but performance and session behavior must be tested with production-sized data. |
| Monitoring, lineage and data quality services | Logging and metadata in Hop; lineage and data quality need separate tools | Gap. Plan for these services separately if PowerCenter reporting or governance depends on them. |
Migration sequence from pmrep inventory to decommission
This sequence turns a PowerCenter repository into a tested set of Apache Hop pipelines and workflows, then retires PowerCenter one workflow group at a time. Each step closes with a named output so the team knows when it can move on. The order matters because the inventory drives grouping, and the parallel run is the only evidence that rebuilt logic matches the original.
Export the repository inventory
Use pmrep ObjectExport or Repository Manager to export mappings, sessions, workflows, worklets, schedules and source and target definitions to XML. The PowerCenter administrator or ETL lead runs the export against each repository folder in scope and stores the files in version control. The step is done when every folder has a dated export and a simple register lists each object, its folder, its owner and the downstream consumers that rely on its target tables. Note that the XML describes design, not runtime behavior, so connection values and session overrides need a separate check.
Profile and prioritize mappings by group
Parse the exports into a spreadsheet or small script that counts transformations per mapping, flags unusual transformation types, and maps each workflow to its business owner and schedule. The ETL lead, with input from the data owners, groups mappings by business domain and by dependency, so that a set of workflows that share targets moves together. Priority goes to low-risk groups that feed few consumers, with high-impact feeds scheduled later. The output is a ranked list of workflow groups with an agreed cutover order, signed off by the data owners.
Rebuild the first group as Hop pipelines
Engineers recreate the mappings in the chosen group as Hop pipelines and their orchestration as Hop workflows, using the Hop GUI and shared metadata for database connections. Because the Hop importer covers Kettle/PDI assets only, there is no automated PowerCenter conversion, so each transformation is rebuilt by hand against the exported specification. The step is complete when every pipeline in the group is committed to a Git repository with a short mapping note that cites the source PowerCenter object.
Run a pilot pipeline on Hop's native engine
Execute the first rebuilt pipeline on the native Hop engine, locally or on a Hop Server, against a copy of the source data. The engineer compares row counts, column-level checksums and sample records against PowerCenter output for the same input window, and records every difference with its root cause. Edge cases such as null handling, date formats, sequence generators and lookup caching are checked explicitly. The pilot is done when the output matches or each variance has an approved explanation.
Scale to Spark, Flink or Beam when volumes demand it
If the pilot shows that the native engine cannot meet the load window, the team reconfigures the same pipelines to run on Apache Spark or through Apache Beam on Flink, selected as a runtime configuration. The platform engineer tests throughput on production-sized data and confirms the cluster sizing with the infrastructure team. The output is a documented runtime choice per group, with measured run times and the cluster capacity it needs.
Operate both pipelines in parallel
For each group, PowerCenter and Hop run side by side on the same inputs while a scheduler submits Hop workflows, because Hop Server does not schedule work itself. Operators compare outputs every run and log discrepancies in the register, and the data owners sign off on reconciled results over an agreed set of business cycles. The parallel run ends for a group only when the owners accept the reconciled outputs in writing, and the team confirms that alerting, restart and failure handling work for the Hop side.
Cut over each workflow group
Once a group passes parallel reconciliation, the team switches downstream consumers to the Hop outputs, disables the matching PowerCenter sessions and workflows, and keeps the PowerCenter objects in a read-only state for a rollback window the owners agree on. The engineer confirms that consumers read from the new targets and that the group's scheduler entries now point to Hop. The step closes with a cutover record per group that lists the switch time, the approver and the rollback procedure.
Decommission PowerCenter after the last group
When every group has cut over and the rollback windows have closed, the team archives the final pmrep exports and repository backups under retention rules set by compliance, then shuts down the PowerCenter services and removes their licenses and servers. The team confirms the archive can be restored for audit questions and that Informatica support or license terms are closed out in writing. The output is a decommission record stating which objects were retired, where the archives live and who approved the shutdown.
How Hop pipelines run on the native engine, Spark, Flink or Databricks
The key point for a PowerCenter migration is that Hop separates design from execution. Teams build a pipeline or workflow once on the Hop GUI canvas, then choose the engine as a runtime configuration rather than rewriting the logic. The native Hop engine can run a pipeline locally on a developer or build machine, or on a remote Hop Server. Hop can also run the same pipeline on Apache Spark natively or through Apache Beam, on Apache Flink or Google Dataflow through Beam, or on Databricks. Before you commit a mapping to a distributed engine, test it on the native engine with representative volumes, because a PowerCenter mapping that relies on session-level behavior may produce different results on a different runtime.
Hop Server is a long-lived process that executes pipelines and workflows, but it is not a scheduler. Something outside Hop must submit the work, whether that is a cron job, an enterprise scheduler, or an orchestrator such as Apache Airflow. This matters for PowerCenter teams because the PowerCenter Integration Service and its workflow scheduler often carry dependencies that were never documented. Map every trigger and dependency from your pmrep exports to an external scheduler before cutover. Hop 2.19.0, released on August 17, 2026, requires Java 21, so confirm that your Hop Server hosts, build images and any Beam or Spark runtimes support that version, and check the Hop download page for the current release before you pin a version.
Deployment choice follows from engine choice. Hop projects can be packaged as the apache/hop Docker image for short-lived runs or a long-lived Hop Server, deployed as exported ZIP resources, or pulled from a Git checkout. The browser-based Hop Web GUI runs from the separate apache/hop-web image. Ask your platform team which of these fits your container and secrets standards, and test how database connections and environment variables resolve on each target. The Spark, Flink and Databricks options also add cluster capacity, networking and licensing questions that sit outside Hop itself, so the cost of these engines should appear as separate lines in your architecture and quote.
Data, connections and integrations to rebuild by hand
A PowerCenter XML export describes mappings and workflows, but a working Hop project also depends on connections, parameters, session behavior and the feeds around the jobs. Each of the cards below is a part of the estate that has to be inventoried and rebuilt deliberately, not carried over by a converter.
PowerCenter XML as the specification
Export folders from Repository Manager or with pmrep ObjectExport and treat the XML as the inventory of sources, targets, transformations and dependencies. It shows what each mapping is supposed to do, which makes it the starting point for designing Hop pipelines. Check that every mapplet, reusable transformation and lookup is in the export set, because a missing object is easy to overlook until a pipeline fails in testing.
Source and target connections as Hop metadata
PowerCenter connection objects must be recreated as Hop metadata for databases, files and message endpoints. Build them in each environment with a parameterized host and credential reference, not a copied value. Verify that connection names used by pipelines match the new metadata, since the Kettle importer's documented limit on same-named database connections shows how naming collisions appear during moves.
Parameter and variable files
PowerCenter parameter files and mapping variables control dates, paths, environment names and filter values at run time. Map each one to a Hop project variable or a pipeline parameter, and decide which values belong in environment configuration and which belong in the job that submits the run. Test each variable under the production naming and default values, because a silently empty parameter can produce a run that completes with wrong data.
Session-level commit and error handling
Session settings such as commit intervals, reject file handling, recovery behavior and error thresholds shape what a failed load leaves behind. The XML does not reliably carry how these behaved in production, so review session logs and agree the intended outcome with the data owners. Rebuild each setting explicitly in Hop, then test restart and partial-failure scenarios with representative data volumes.
Upstream and downstream feeds
Many PowerCenter workflows start when a file lands or a message arrives, and end by notifying a warehouse load or a reporting job. Document each trigger, file path, queue, handoff and success signal from the scheduler and the surrounding systems, not only from the workflow definitions. Confirm with the owning teams which feed formats and timings must stay identical during cutover.
How the move differs by repository size and starting point
A small PowerCenter repository, with a few dozen mappings, few workflows and little shared logic, is the simplest case. The inventory is short enough to review by hand, and a single engineer can often rebuild the whole set as Hop pipelines and workflows in one pass, then compare row counts and sample outputs against the PowerCenter results. The main risk is not volume but undocumented behavior, such as a session override or a parameter file value that nobody wrote down.
- Inventory by hand: Export objects with pmrep ObjectExport or Repository Manager XML and read each mapping against its session and workflow.
- Rebuild in one pass: Map each source, target and transform to Hop transforms and keep a one-to-one list of names.
- Check parameters: Pull every
$$parameter and parameter file value into Hop variables and project metadata. - Run both side by side: Keep PowerCenter running for a short comparison window on the same input.
- Plan the scheduler separately: Confirm how workflows are triggered, since Hop Server does not schedule work on its own.
Before you start, confirm with your own repository owner whether any sessions write to targets outside the warehouse, because those are easy to miss in a small inventory.
A large repository with heavy reuse of mapplets and reusable transformations behaves differently. One mapplet may feed dozens of mappings, so a single change in shared logic can affect many outputs. Rebuilding each mapping separately creates copies that drift apart over time. The better approach is to identify the reusable pieces first, rebuild each as a Hop pipeline or a shared sub-pipeline, and only then rebuild the mappings that call them.
- Map reuse first: Use the XML exports to list every mapplet and reusable transformation and count how many mappings reference each one.
- Rebuild shared logic once: Create a single Hop sub-pipeline or shared transform pattern for each high-reuse mapplet.
- Group by dependency: Rebuild in layers, starting with mapplets that have no upstream dependencies.
- Set a naming and version convention: Put Hop projects under Git so changes to shared logic are reviewed and traceable.
- Budget for testing: Test shared logic against each downstream consumer, not only in isolation.
Ask your implementation partner or internal team to produce a dependency map from the XML exports before committing to a schedule, because the reuse graph determines the order of work more than the mapping count does.
A team that writes strong SQL but has little Java experience is well placed for much of this work. Many PowerCenter mappings are mostly source qualifiers, lookups, joins, aggregations and expressions that map closely to SQL. Hop's visual pipelines and its database transforms let such a team keep the logic in SQL statements where that is the clearest option, and reserve scripting transforms for the few cases that need them. Java skills matter most when you run Hop on Spark or Flink, or when you extend the platform.
- Move logic into SQL: Keep lookups, joins and aggregations as SQL in database transforms where the database can run them efficiently.
- Limit scripting: Use the scripting transforms only for expressions that SQL cannot express cleanly, and document each one.
- Pick the engine deliberately: Start on the native Hop engine for batch work and add Spark or Flink only when volume requires it.
- Plan targeted training: Train on Hop metadata, variables and project structure, which are the parts a SQL-focused team most often finds new.
- Use an outside partner for edge cases: Confirm in the scope which Java-dependent work, if any, is covered by a fixed-scope engagement.
Check early whether your target database dialect is among the listed options, and whether your SQL logic depends on vendor-specific functions that will need rewriting.
A team that already runs Pentaho Data Integration or Kettle jobs next to PowerCenter has a head start on a subset of the work. Apache Hop started from Kettle and provides an importer that converts Kettle jobs to Hop workflows, transformations to Hop pipelines, and kettle.properties and shared database connections to Hop metadata. That importer does not cover PowerCenter, so it helps only with the Kettle portion of the estate. Keep the two inventories separate so the Kettle jobs are not counted twice or mistaken for PowerCenter mappings.
- Run the importer on the Kettle subset: Use the File menu import option or the hop-import command-line tool on the Kettle project.
- Review known limitations: The importer keeps only one copy of same-named database connections and does not import the metastore, so check connections by hand.
- Keep PowerCenter inventory separate: Rebuild PowerCenter mappings from the pmrep XML exports, not from the imported Kettle work.
- Reconcile shared connections: Where both estates use the same databases, consolidate connections once in Hop metadata.
- Test imported jobs in Hop: Run imported transformations against the same test data used for the original Kettle jobs.
Confirm with the Pentaho or Kettle owners which of their jobs are still in production, since imported jobs need the same validation as rebuilt PowerCenter work.
Questions buyers ask before moving PowerCenter to Apache Hop
Is there an automatic converter from PowerCenter to Apache Hop?
No. There is no automatic PowerCenter importer for Apache Hop. Hop's import feature converts Kettle (Pentaho Data Integration) jobs and transformations, not PowerCenter mappings or workflows. That means PowerCenter exports are useful as an inventory and specification, but each mapping and workflow still has to be designed as a Hop pipeline or workflow by hand. Ask any partner to show how they will handle each PowerCenter transformation type, how they will track the rebuild, and where they will record the differences between PowerCenter and Hop behavior.
What drives the effort and time for a PowerCenter to Hop move?
The main driver is the number and complexity of mappings, not the total number of workflows. Effort rises with custom transformations, heavy use of lookups and stored procedures, complex parameter files, error handling, incremental loads and the number of source and target systems. Teams with many simple, repeatable mappings can often standardize their rebuild. Teams with bespoke logic, undocumented business rules or many dependencies on the PowerCenter scheduler will need longer analysis and testing. Ask for an inventory-based estimate that lists each mapping by complexity before agreeing to a timeline.
What does our internal team need to provide?
Your team provides the knowledge that the repository does not hold. This includes business owners for each data flow, the rules behind filters and calculations, source and target system access, test data that reflects production, and decisions on how to handle rejects and failures. Someone must also own the connection inventory, because PowerCenter connections do not carry over. Expect to name a technical lead who can approve design choices and a business reviewer who can sign off reconciled outputs.
Can we do the migration without outside help?
Yes, a capable internal data engineering team can rebuild pipelines in Apache Hop, since the project is open source and the GUI is documented. The questions are capacity and skills. Rebuilding PowerCenter logic, validating results, operating Hop Server and building a deployment pipeline all take time away from production work. A common approach is to bring in outside help for the design standards, the first batch of pipelines and the runbooks, then have the internal team complete the rest. Whichever route you choose, write down who owns each part.
How does a parallel run work during cutover?
A parallel run executes the PowerCenter and Hop versions of the same flows against the same inputs for an agreed period, then compares outputs row by row or by control totals. Differences in null handling, data type conversion, sort order and date logic are the usual sources of mismatch, so define the comparison rules before the run starts. Keep PowerCenter as the system of record until the business signs off, and plan the rollback steps for each pipeline. Hop Server does not schedule work, so the cutover must also move scheduling to an external orchestrator.
What happens to data quality and catalog services?
PowerCenter does not include the Informatica data quality and catalog services in the same way that IDMC does, but many teams use separate Informatica products alongside it. Apache Hop covers transformation and orchestration, not a managed data quality or catalog service. If your PowerCenter flows depend on profiling, cleansing or lineage from other Informatica tools, list them now and assign an open-source or in-house replacement. Confirm the scope of each replacement in writing, because a Hop migration does not replace those services automatically.
What should we ask for in a written scope?
A written scope should state the systems in scope, the inventory source and its version, the number of mappings and workflows by complexity, the target Hop version and Java runtime, and the execution engine for each pipeline. It should also define the parallel run period, comparison method, acceptance criteria, documentation, handover, and what happens to schedulers and connections. Ask for exclusions in plain language, such as data quality or catalog work, and for the deliverables and dates tied to each phase. Require a named contact for change requests. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the written scope is where these details belong.
What usually goes wrong and how to prevent it
Most failed PowerCenter-to-Hop moves do not fail in the engine. They fail in assumptions made during inventory, import, testing and cutover. The cards below cover the risks that recur most often and the checks that catch them before production depends on the new pipelines.
Assuming an automatic PowerCenter converter
Hop's importer handles Kettle (PDI) jobs and transformations, not PowerCenter mappings, workflows or sessions. Teams that plan around a conversion step lose weeks discovering that every mapping is a manual rebuild. Treat the pmrep XML exports as a specification, estimate rebuild effort per mapping class, and confirm with the Hop project which PowerCenter objects have a direct equivalent before scoping.
Undocumented session overrides
PowerCenter session properties, such as per-session connection overrides, commit intervals, error handling, pre- and post-session SQL and parameter files, often change behavior without appearing in the mapping XML. Hop pipelines will run with the logic you copy, not the behavior your sessions had. Pull session and workflow properties from the repository alongside the mapping exports and record each override in a migration register.
Same-named connections collapsing on import
Hop's Kettle import keeps only one copy of database connections that share a name, so environments such as dev, test and production can silently merge into one definition. The same risk applies to hand-built metadata when teams reuse names across projects. Give every connection an environment-qualified name, confirm which definition each pipeline resolves at run time, and check connections against a documented list before the first run.
Drift during parallel run
Rebuilt pipelines often diverge from PowerCenter logic in null handling, sort order, date conversion and lookup caching, and the difference shows up only in reconciled outputs. A parallel run that compares row counts alone misses these errors. Define reconciliation queries per target table, compare column-level checksums over agreed windows, and log every accepted difference so reviewers can sign off each one.
Scheduler gaps after cutover
PowerCenter workflows carry schedules, dependencies, restart behavior and alerting that Hop does not replace. Hop Server is not a scheduler, so an external orchestrator must submit each pipeline or workflow. Teams that switch mappings but forget dependencies, retries or failure notifications discover the gap when a load runs late or silently skips. Inventory every schedule and dependency from the repository, assign each one an owner, and test failure paths before retiring the old jobs.
Java and engine version assumptions
Apache Hop 2.19.0 requires Java 21, and the official Docker images are built with OpenJDK 21. Hosts, base images or Spark and Flink clusters still on older Java will fail at startup or in worker processes. Spark, Flink and Beam runtimes add their own compatibility matrices. Confirm the Java version on every Hop host and worker, pin the Hop release in your build, and run a smoke test on each target engine before the migration plan is approved.
What drives cost and duration in a PowerCenter rebuild
This table lists the main factors that move the cost and elapsed time of rebuilding PowerCenter work in Apache Hop. Read each row as a driver: why it changes effort, what keeps it manageable, and what to request in a written quote. Mapping count and reuse of mapplets usually matter most, so ask for the inventory breakdown before comparing any estimate.
| Driver | Why it moves cost | How to keep it down | What to ask for in a quote |
|---|---|---|---|
| Mapping count and complexity | Each mapping needs design, build and testing. Lookups, slowly changing dimensions, parameter files and custom SQL overrides add more work than simple pass-through loads. | Classify mappings into simple, moderate and complex tiers from the pmrep XML inventory. Retire unused mappings before rebuilding. | Effort per complexity tier, with the number of mappings in each tier taken from your inventory. |
| Mapplet reuse | A mapplet used in many mappings is built once in Hop but must be tested in every context. Heavy reuse lowers build effort but raises regression scope. | Rebuild shared mapplets first as reusable Hop pipelines with documented inputs and outputs. | How reused mapplets are counted, and whether regression testing is priced per consuming pipeline or per shared component. |
| Number of source and target connections | Each database, file share, message queue or API needs a Hop metadata connection, credentials handling and connectivity testing. Connection drivers and dialect differences add hidden work. | Inventory connections from the PowerCenter repository early and reuse one Hop metadata entry per system. | Connection count, the drivers and dialects involved, and who provides credentials and network access. |
| Scheduler and workflow dependencies | PowerCenter workflows, worklets, event waits and external schedulers define run order and failure handling. Hop workflows and Hop Server do not schedule work, so these must be reproduced in an external orchestrator. | Map each workflow dependency and failure path before rebuilding. Decide early which orchestrator will submit Hop work. | Whether orchestration is in scope, which scheduler will be used, and how cutover with the existing scheduler is handled. |
| Reconciliation depth | Row counts, checksums, field-level comparisons and business sign-off each add test cycles. Deeper reconciliation protects against silent data differences but takes longer. | Agree the reconciliation rules per data set, and automate comparisons where the data allows. | The reconciliation method for each critical target, the number of test cycles included, and who signs off results. |
| Execution engine choice | Running on the native Hop engine, Hop Server, Spark, Flink or Databricks changes the infrastructure, tuning and skills required. Engine changes after build can reopen testing. | Choose the engine from measured volumes and latency needs, and start with the simplest engine that meets them. | Which engine is assumed, the sizing basis for it, and whether performance testing is included. |
| Team skills and availability | Teams that know Kettle or PowerCenter ramp up faster on Hop. Teams new to Java, Git-based project deployment and Docker need time to learn these as well. | Pair PowerCenter developers with Hop practitioners and document conventions in a shared project template. | Named roles, their expected allocation, and whether knowledge transfer and handover are included. |
What to ask for in a written scope before work starts
A fixed-scope agreement for a PowerCenter exit should start with a frozen inventory baseline: a pmrep ObjectExport or Repository Manager XML export of every folder, mapping, mapplet, workflow, worklet and session in scope, with the export date and the repository version recorded beside it. Ask the vendor to state the mapping and workflow count in that baseline, and to list which objects are excluded and why, such as retired jobs or objects that exist only in a development folder. Name the target engine too. A scope that says "Apache Hop" without naming the Hop engine, a remote Hop Server, Spark through Apache Beam, Flink through Apache Beam or Databricks leaves the sizing and the test environment undefined. Confirm the Java version the Hop runtime will use, since the Hop download page lists Java 21 for the current release, and confirm it against your own build standards before signing.
Reconciliation and cutover acceptance are where scopes usually fail, so write the criteria down before any pipeline is built. For each in-scope workflow, the agreement should name the sample of source and target data to compare, the row counts, the checksums or column-level comparisons, the tolerance for differences, and who signs off each result. Specify how exceptions are handled, including the documented behavior of PowerCenter that a rebuilt pipeline will not match exactly, such as reject handling, sequence generators and session-level commit settings. The cutover clause should state the parallel-run period, the rollback procedure, and the acceptance owner on your side. Handover documentation should cover the Hop project layout, environment and metadata files, the scheduler integration with the Hop Server, and a runbook for restarts and failed runs.
Finally, record what support continues after handover. Decide whether the agreement includes a defined warranty period for defects found after cutover or whether ongoing support, upgrades and testing will be a separate retainer, and get the response expectations and their scope in writing rather than assuming them. Ask who owns the Hop Server hosting, the Java and operating system patching, and the Docker images or Git repository used for deployment. List the internal roles the work depends on, including a data owner per source system and a named approver for production changes. Any figure for duration or effort in the quote should come from the written scope and be traceable to the inventory counts, not from a general estimate.
How DeployOpen scopes and runs a PowerCenter to Hop migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a PowerCenter to Apache Hop move, we start from a written inventory of mappings, workflows and connections, then rebuild and test pipelines in the environment where they will run.
How we scope
- Inventory PowerCenter repository objects from pmrep XML exports, covering mappings, workflows, sessions and schedules in the agreed scope
- Record which connections, parameter files and runtime settings the XML does not carry and must be confirmed with the client
- Agree in writing which workloads move to Hop pipelines, which target execution engine applies, and which items stay out of scope
- Set out deliverables and timelines in the fixed-scope document before work starts, with ongoing support offered as a retainer
How we build
- Rebuild mappings as Hop pipelines and workflows, and use the Kettle importer only where the source actually came from Kettle or PDI
- Set up Hop Server, the apache/hop Docker image or a Git-based project layout in the client's own infrastructure
- Choose the native Hop engine, Spark, Flink or Databricks per workload, and benchmark each choice against agreed test data
- Replace the scheduling role of PowerCenter workflows with an external scheduler, since Hop Server does not schedule work itself
How we hand over
- Run reconciliation tests comparing row counts, key totals and target outputs from PowerCenter and Hop for each migrated object
- Document each pipeline, its parameters, its connections and the behavior differences found during testing
- Deliver runbooks for deployment, rollback, credential handling and parallel running during cutover
- Train the client's data engineers on the Hop GUI, project structure and the operational procedures agreed in scope
How we support
- Offer ongoing support, upgrades and continuous testing for the Hop stack as a retainer, scoped in writing
- Plan Hop upgrades against the Java version each release requires, so runtimes stay current with the client's change process
- Keep backups and configuration of Hop metadata and Hop Server under the client's own backup policy and review them periodically
- Confirm with the client which compliance evidence they need, and prepare the controls and records, while independent auditors issue any assessment
