🏔️ Summit 2026 Feature
Legacy Reader Base Migration to Workflows moves reader-enabled legacy bases into the modern Workflows tool while preserving reader process data during the transition.
🏗️ Provisional document
This feature is pending release, and this document may change over time. Check What’s New for the latest releases.
Legacy Reader bases predate the modern Workflows tool. In that older model, a query base could be enabled for Reader, and reader state such as bins, bin history, queue assignment, and related reader data lived in legacy Reader structures.
Legacy Reader Base Migration to Workflows moves those reader-enabled legacy bases into the current workflow model. After migration, each legacy Reader base is represented by a workflow that uses the original base name. Most of the work happens behind the scenes, so the migration is primarily a structural change rather than a new configuration process for users.
What the migration creates
The migration creates a workflow for each migrated legacy Reader base and associates the related Reader resources with that workflow. These resources can include bins, reader tabs, and the rules that move records through the reader process.
Existing reader process data also moves into the workflow structure. This gives the migrated process a modern workflow home without requiring institutions to manually rebuild historical reader state.
Because the workflow uses the name of the original legacy Reader base, migrated processes should be recognizable in Database → Workflows.
What changes in Slate
After a legacy Reader base is migrated, its reader process is managed from the Workflows tool instead of the legacy Reader tools. Migrated bins no longer appear in the legacy bin tools because the workflow becomes the configuration home for that process.
Readers continue to use Reader to work records through the process. The migrated workflow provides the bins, queues, tabs, and review experience that support the reader process.
How compatibility is preserved
The migration is designed to keep existing operations working while Slate moves reader data into the workflow structure.
Reports and queries: Slate keeps legacy reader data in sync during the transition so reports and queries that reference reader bin or queue information can continue to work.
Imports: Imports that previously mapped to bin or queue destinations can continue to route records to the corresponding workflow destinations when a migrated workflow exists.
Reader data: Historical reader information moves into the workflow structure while compatibility with the legacy data model is maintained during the transition.
This compatibility gives institutions time to move forward with Workflows without immediately rewriting every report, query, or import that references legacy Reader data.
Migration timing
Migration timing may vary by environment. A typical rollout starts with review in a test environment before production migration. This gives institutions time to confirm that their migrated workflows, reports, queries, and imports behave as expected.
Some environments may not expose migration controls directly. If migration controls are not available in your database, coordinate timing with Technolutions.
After migration
After a migration, review the migrated workflow before relying on it in production. Focus on representative records and the parts of the process that carry the most operational risk.
The migrated workflow appears with the expected name.
Expected bins, queues, reader tabs, review forms, and dashboards are available.
Representative records appear in the expected workflow bins and queues.
Important reports, queries, and imports continue to return the expected reader data.
For details about building and maintaining workflows, see Workflows Overview and Planning Workflows.