We’re attempting to upgrade our HR Core module from 10.x to ICS 2021 using the Upgrade Utility, but the schema migration consistently fails at the 47% mark. The error log shows missing index references on the EMPLOYEE_BENEFITS table, specifically IDX_EMPBEN_STATUS and IDX_EMPBEN_EFFDATE.
The upgrade utility runs preflight checks successfully, but during the actual schema transformation phase, it throws:
We’ve verified schema prerequisites according to the migration guide, and our source database passes all compatibility checks. Has anyone encountered missing index issues during HR Core upgrades? We need guidance on whether to manually create these indexes before retrying or if there’s a rollback procedure to safely revert and investigate further.
I’ve handled several similar HR Core upgrades with custom schema modifications. Here’s the complete resolution approach addressing your schema prerequisites, manual index handling, and rollback safety:
Schema Migration Prerequisites:
First, generate a complete schema difference report using Infor’s Schema Comparison Tool (available in the upgrade toolkit). This will identify ALL deviations from the baseline schema, not just the obvious index naming issues. In your case, custom index names from previous modifications are blocking the upgrade.
Manual Index Creation Process:
Do NOT manually rename or drop indexes during an active upgrade. Instead:
Fully roll back the current upgrade attempt using the Upgrade Utility’s rollback function
Create a pre-migration script that renames custom indexes to match expected names:
ALTER INDEX IDX_EMPBEN_STAT_01 RENAME TO IDX_EMPBEN_STATUS;
ALTER INDEX [other_custom_name] RENAME TO IDX_EMPBEN_EFFDATE;
Document these changes in your upgrade runbook
Run the Upgrade Utility’s preflight validation again to confirm all schema prerequisites are met
Upgrade Rollback Handling:
Before retrying, ensure you have:
Full database backup taken immediately before the upgrade (not the one from initial attempt)
Export of all custom configurations and index definitions
Validated rollback procedure by testing the restore process in a non-production environment
Documented rollback time estimate (typically 2-4 hours for HR Core)
The Upgrade Utility maintains rollback checkpoints at each major phase. If you need to rollback after fixing the index names, use the utility’s built-in rollback rather than manual database restoration. This preserves audit logs and allows you to resume from the last successful checkpoint.
Critical Note: After renaming indexes, verify that any custom reports, integrations, or scheduled jobs that reference these indexes by name are updated accordingly. The upgrade will succeed, but dependent processes might fail post-upgrade if they’re still using old index names in their queries.
Run the upgrade in maintenance window with at least 6-hour buffer for unexpected issues. The schema migration phase typically takes 45-90 minutes for HR Core, but with custom modifications, allow double that time.
This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if your source database has custom indexes that weren’t documented in the baseline schema. Run a comparison between your current schema and the standard ICS 2021 schema definition. The upgrade utility expects specific index structures, and if you’ve added custom indexes in production, they might conflict with the migration script’s assumptions.
This is a known issue with certain 10.x to ICS 2021 upgrade paths. The problem occurs when the source database has been patched inconsistently or when certain hotfixes were applied that modified index structures. Before proceeding, you need to verify your exact source version and applied patches. The Upgrade Utility has different migration scripts based on the specific source build number, and using the wrong migration path can cause these index mismatches. Check your upgrade logs for the detected source version and confirm it matches your actual environment.
I’d recommend taking a database snapshot before attempting any manual fixes. For the immediate issue, you can query your current index definitions with:
SELECT index_name, column_name
FROM user_ind_columns
WHERE table_name = 'EMPLOYEE_BENEFITS';
This will show you what indexes actually exist versus what the upgrade expects.
Thanks for the suggestions. We ran the index query and found that IDX_EMPBEN_STATUS exists but with a slightly different name (IDX_EMPBEN_STAT_01) due to a custom modification from 2019. The upgrade script is looking for the exact name. Should we rename the existing index or drop and recreate it with the expected name before rerunning the upgrade?
Don’t rename indexes directly during an active upgrade process. Instead, document all custom index names and their purposes, then use the Upgrade Utility’s pre-migration cleanup option. There should be a configuration file where you can map custom index names to expected standard names. This prevents the utility from trying to create indexes that already exist under different names. Also check if you have any custom triggers or stored procedures referencing these indexes, as they’ll need updating too.
Tested this on Infor CloudSuite HR Core 2023.x upgrade and the Schema Comparison Tool immediately flagged our three misnamed custom indexes before the migration even attempted to run.