Considerations for migrating from Unica to RPI
Executive summary
Migrating from HCL Unica Campaign to Redpoint Interaction (RPI) involves both technical and operational shifts. This document outlines the critical considerations to ensure a successful transition, including platform comparisons, migration strategy, user training, and data management. Compared to Unica, RPI offers several key advantages, such as native real-time campaign support, built-in Customer Data Platform (CDP) functionality for advanced audience management, faster development cycles through a drag-and-drop, metadata-driven design, and cloud-ready deployment with robust integration capabilities. These benefits position RPI as a modern, flexible solution to support evolving marketing needs.
Platform overview
Feature | HCL Unica | RPI | Details |
|---|---|---|---|
UI/UX | Java-based rich client | Web-based, modern UI | HCL Unica relies on a Java-based rich client interface, which can feel dated and require local installations. In contrast, Redpoint Interaction offers a modern, web-based UI that provides easier access, better usability, and streamlined user experiences across environments. |
Campaign design | Single Flowchart-based | Multi-Level Workflow-based (drag & drop) | Unica uses a single flowchart-based approach for campaign design, offering a linear structure that can become complex for multi-step workflows. RPI improves on this with multi-level, drag-and-drop workflows that allow more visual clarity and modular campaign building. |
Database support | On-prem or JDBC | Broad SQL support; cloud & on-prem | HCL Unica primarily connects to on-premises databases via JDBC, limiting flexibility for cloud strategies. Redpoint Interaction supports a wide range of SQL dialects and works seamlessly across both cloud and on-premises data environments, enabling greater deployment flexibility. |
Scripting | Built-in expression language | T-SQL (SQL-based expressions) | Unica features a built-in expression language for defining campaign logic. Redpoint Interaction, on the other hand, leverages T-SQL and SQL-based expressions, offering familiar syntax for users proficient in SQL and enabling powerful data transformations directly within workflows. |
Integration | Primarily batch/API | Real-time, API, cloud connectors | Integration in Unica is largely batch-oriented or API-based, often requiring scheduled processes. RPI expands capabilities with real-time integrations, extensive APIs, and pre-built cloud connectors, allowing for faster data access and responsiveness to customer behaviors. |
CDP capabilities | Limited native CDP features | Built-in CDP functionality | HCL Unica provides only limited native CDP functionality, requiring additional tools for comprehensive audience management. Redpoint Interaction includes built-in CDP capabilities, enabling advanced audience creation, identity resolution, and real-time personalization within a unified platform. |
Capabilities comparison
Unica feature | RPI approach | Details |
|---|---|---|
Campaign work is all done in a single screen | Layered approach to campaign creation | When building a campaign within each of the tools, there are differences in the methodology of how to do so. Within Unica, the entire campaign is built within a single screen known as a flowchart. Within RPI, there is a layered approach or building blocks when creating a campaign; then these pieces are put together to create an Interaction or workflow. |
Merge Function / Purge Function | Multi Filters / Embedded Selection Rules / Suppressions | Within Unica a user has the ability to use a Merge/Purge process block to bring records from previous blocks together while also being able to dedupe records based on a given order. This process block can also be used to remove records (Purge) from the working population. RPI doesn't currently have a Merge/Purge functionality within it, but the same results can be achieved by reorganizing how a user builds their workflows to take advantage of the process blocks that RPI offers (Multi Filters/Embedded Selection Rules/Suppressions). |
Raw SQL Capabilities | Ability to use custom SQL in Selection Rules and Attributes or leverage RPDM to perform complex logic or calculations | Unica gives the campaign user the ability to use Raw SQL within a given flowchart for pre/post processing or even as selection criteria. These Raw SQL rules do not depend on the table catalogue to process against the database. To accomplish this same type of functionality within RPI, a user has the ability to use custom SQL attributes, custom SQL rules (based off table joins) or they can use a combination of RPI and RPDM using Data Process Projects for more complex types of logic. |
Flexibility on template creation/usage (save or upload sections of a flowchart) | Ability to create audience or interaction templates as a whole, re-use underlying components, copy/paste components | When creating flowchart templates within Unica, a user has the ability to save pieces or sections of a flowchart as a template that other users can reuse in the future where needed. RPI will only allow a user to save full audiences and/or interactions as templates, so when creating templates in RPI, there will need to be more thought/planning around how they are built. |
Contact History saved in separate schema | Offer History can be saved to same schema as marketing tables, allowing for easier selection within campaigns | Unica has the notion of Contact History tables that live within a different schema by default, which can cause issues when running campaign logic against these tables. RPI has Offer History, which by default lives on the same schema as the Marketing tables. This makes it easier for a user to create rules and run selection logic against Offer History within a given workflow. |
Ability to run a single box/branch when testing a campaign | Run individual selection rule tests to validate blocks of logic; execute full audience or interaction in test mode to get waterfalls and output record counts | When running a flowchart within Unica, a user has the ability to run a flowchart multiple ways: Run Flowchart, Run Branch, or Run Process Box. When running a workflow within RPI, the user only has the ability to run single selection rules or the complete audience or interaction. |
Ability to have multiple catalogs saved | RPI allows for one "catalog" in which joins are defined within RPI configuration and the ability to reference auxiliary database sources | Within Unica there is the ability to create multiple catalogs, which can be more focused by campaign type or given brand. These catalogs can be used individually and also merged together when needed. RPI has the notion of a single “catalog” in which all of the table joins are created at the time of implementation. |
Can have multiple Base tables within a given flowchart | RPI uses audience definitions to decide which "key" should be used for a given campaign ( | A Unica catalog allows for multiple “Base” tables, which don't require joins to any tables as long as each table has the same “key” within the table layout. RPI can have multiple audience definitions created that are associated to a given “key” within a given “Base” table, but all of the tables are joined using single- or multi-join logic within the configuration to allow for the different definitions to be used. |
Manual version control to track changes | Automated version control for each of the campaign artifacts | When objects are being created or modified within Unica, the responsibility to leave notes for version control is on the user who is doing that given task so that other users are able to know what has been done. RPI has an internal set of tables that keeps a record of the history for each item within the tool for version control. This helps troubleshoot any changes that have happened and which user made those changes. |
Users have access to every field on a given database table | Ability to control what campaign users can access within RPI via permission controls and attribute configuration | When a table has been added to a given flowcharts catalog, then all users have access to every field that lives on that given table. This can add noise to the UI when a user is looking for something specific. Within RPI, the admin user has the ability to only expose required fields to the end user and limit everything else until they might be needed. This helps to keep the UI cleaner and also prevent a user from selecting the wrong field by mistake. |
Audience Level Switching Process block | RPI has the ability to use different resolution levels in order to allow for selections to be performed using different database keys | Within Unica there is a process block that allows a user to swap audience levels ( |
Migration considerations
Functional mapping
Flowcharts → Workflows
Map each Unica flowchart to RPI workflows using similar logic blocks (e.g., Select, Merge/Purge → Filter, Multi Filter, Split, Suppressions).Table Mappings → Catalog
Unica allows for multiple sets of table mappings that can be used within a flowchart, while RPI allows for a single catalog that depends on joins to successfully execute a workflow. Refer to Configuring the catalog for additional information.Strategic Segments → Audience Snapshots
Audience Snapshots in RPI act like static lists of records that can be refreshed on a schedule basis or a manual run. Refer to Creating an Audience Snapshot for additional information.
User access and roles
Map Unica user roles and permissions to RPI roles and permissions: Within RPI, an admin user has the ability to create multiple user groups in which they can assign certain sets of permissions for each group. This allows the admin to control what a specific user/group sees within RPI. In the following doc topics, it explains how to set up users and user groups as well as an example of how different permissions can be set up within the different groups.
Automation and Scheduling
Review automated jobs in Unica (daily batch runs, schedule triggers).
Rebuild those using RPI’s different schedule process blocks within an Interaction. Refer to Interaction Designer: Triggers for details.
RPI allows for external triggers to be used to execute a workflow. To configure that option, refer to the following topic, which walks through the process of configuration: Triggers tab set.
Reporting
Identify existing Unica reports and dashboards.
Re-create using RPI export options or integrate with BI tools like Power BI or Tableau.
Business Intelligence (BI) tools can access Redpoint Interaction (RPI) data by connecting directly to the relational or cloud databases where RPI stores its campaign and audience data, using standard connectors like ODBC, JDBC, or native drivers. RPI also enables data exports to tables or flat files, which BI tools can easily read for reporting and analysis. In cloud deployments, RPI writes data directly into platforms like Snowflake or Redshift, ensuring seamless integration with BI solutions. Although BI tools typically don’t connect to RPI’s APIs directly, developers can extract data via APIs into intermediate storage for analysis. Secure access management is essential, often involving dedicated reporting views or schemas to protect sensitive marketing data while enabling robust insights through BI platforms. Refer to Reporting Hub for additional information.
Technical migration steps
Inventory Current Unica Assets: Flowcharts, campaigns, offers, cells, data sources, derived fields.
Data Model Alignment: Clean up and migrate schema definitions to RPI.
Workflow Re-creation: Translate flowchart logic into RPI workflows using SQL filters and activities.
Test & Validate: Validate workflow logic, offer personalization, and output counts.
Deploy & Monitor: Launch campaigns in stages and monitor performance.
Training and change management
User Training: Schedule RPI training workshops focused on UI navigation, workflow building, and offer design.
Documentation: Provide quick-start guides and functional maps.
Center of Excellence: Establish SMEs or champions during the transition phase.
Potential challenges
Learning curve for SQL-based logic and placeholder model.
Users will need to understand how SQL logic works within selection rules and also within SQL Attributes to be able to re-create what has been defined within Unica.
Users will need to document each of the placeholders they have within Unica so that they can be rebuilt within RPI. Unica placeholders can be built on a flowchart-by-flowchart basis, where RPI needs to be done within the overall system configuration.
Redesigning campaign logic for RPI’s workflow-centric structure.
Users will need to consider each of the building blocks that need to be created for each of the workflows they'll need to build. Work to make pieces more reusable across the platform for quicker campaign builds.
Ensuring data access and performance with real-time requirements.
Offer versioning and history tracking requires implementation planning.
Unica does not have a built in version control or history tracking for the items within a given flowchart. When users make changes or updates to flowcharts, it is the user’s responsibility to add a note based on the update that was made. RPI keeps the history of each piece of a workflow, which allows a user to look back to see what was changed and by whom.
Final recommendations
In closing, we recommend a phased migration:
Begin with one or two low-risk campaigns, allowing teams to become comfortable with Redpoint Interaction (RPI) while limiting exposure.
During user-acceptance testing, run Unica and RPI in parallel to validate results and maintain business continuity.
As you progress, create reusable RPI templates to speed future campaign onboarding and enforce best practices.
Finally, consider engaging Redpoint Global or a certified implementation partner for expert guidance and accelerated time-to-value.