Migrate Plugins to Verint Community 14

Prerequisites

Overview

Verint Community 14 changes how external plugins are created, built, and packaged. Existing plugins should be migrated into a new Community 14 plugin project instead of being copied forward as-is. There is not an automated plugin migration process.

Why migrate this way?

Migrating an existing plugin into a new Community 14 plugin is a one-time cost that improves long-term upgrade safety and development workflow.

The new template-based approach gives each plugin its own project, local Community stack, build output, and optional factory default assets. This makes it easier to keep the complete plugin source together, including scripted components such as widgets, embeddables, automations, and emails, without relying on exported scripted defaults and without including the platform's own assets.

Community 14 plugin projects also build against the Verint.Community.Platform NuGet type reference package, which exposes the supported, upgrade-safe in-process API surface across multiple namespaces, mostly unchanged from previous (Telligent.Evolution.Extensibility.*). If a plugin cannot compile against that package, it is using types or patterns that are not considered upgrade-safe in Community. This prevents plugins from depending on non-API implementation details or direct Community data access that could break during upgrades.

Plugins also no longer have access to query Community's own database outside of the API. While this can also present one time migration challenges, it improves the safety and performance of plugins going forward.

Migration Process

1. Create a new empty plugin

Create a new Community 14 plugin project using the steps in Developing a Plugin.

Start with the template options that match the plugin you are migrating. For example, include factory default provider options if the old plugin owns scripted widgets, embeddables, automations, or email assets.

dotnet new community-plugin --name MyMigratedPlugin

For plugins with scripted assets, scaffold the matching provider types up front:

dotnet new community-plugin \
  --name MyMigratedPlugin \
  --implementScriptable \
  --implementWidgetProvider

The generated project includes a local Compose-based Community stack, build tasks, deployment paths, and source-controlled cfs/ locations for supported scripted assets.

2. Move code and assets into the new project

Migrate the old plugin source into the generated Community 14 project in small pieces:

Move plugin classes, configuration, resources, and supporting code into the new project.
Move scripted components into the generated cfs/ structure when the plugin owns factory default widgets, embeddables, automations, or emails.
Build the plugin and fix compile errors against the Community 14 API surface.
Start the local stack, enable the plugin, and validate runtime behavior.
Repeat until the plugin compiles, installs, enables, and runs.

Do not treat build errors against the Verint.Community.Platform package as simple reference problems. They identify code that depends on an API, plugin type, or implementation detail that changed in Community 14.

Common Changes to Review

API surface

Community 14 plugin projects compile against the supported in-process API surface only. Remove dependencies on internal assemblies, implementation types, or APIs that are not present in Verint.Community.Platform.

Use the API Changes, In-Process API and the Developing a Plugin guidance to identify supported replacements.

Data access

Plugins can no longer directly access Community's own data outside of APIs, including through direct SQL access. The only exception is to join against the new read-only [Api].[te_vw_v1_permissions_EffectivePermissions] permissions view.

For storing and accessing custom SQL data, review Managing Data Storage and ISqlServerConnectedPlugin Plugin Type. For plugins that previously stored their own data in the dbo schema, implement IDboAccessSqlServerConnectedPlugin to provide limited, read-only, access to the data during a plugin's installation phase in order to migrate the data out.

Plugin types and scripted assets

Some plugin types and factory default provider patterns have changed in Community 14. When migrating plugins that include scripted assets, scaffold the matching provider type in the new project and move the files into the generated cfs/ structure.

Editing scripted components in the plugin project's within Community in the plugin project's Compose stack will ensure correct placement in its local cfs, as the stack is configured in Development Mode where factory default editing is supported.

Common template options include:

--implementWidgetProvider
--implementAutomationProvider
--implementEmbeddableProvider
--implementEmail
--implementScriptable

See Developing a Plugin for the supported development workflow.

Packaging and source control

Community 14 plugin projects are intended to keep the plugin's buildable source and scripted assets together. Prefer committing the generated project, plugin source, and cfs/ assets instead of committing exported scripted components or DLLs.