1. What is Product Group Code and Why It Changed

Product Group Code was the original way to classify items in older versions of Business Central and Navision. As businesses grew and needed more detailed classification, Microsoft created a new and better solution: the Item Categories feature. Because of this, Product Group was discontinued. It no longer exists in Business Central, and you cannot access the Product Group Code field on the Item Card page anymore.

2. How Item Category Code Works Now

Item Category Code is not just a replacement for Product Group Code. It is a redesign of item classification.

Where Product Group allowed only two levels (Item Category → Product Group), Item Category Code allows unlimited nesting. An item belongs to a single Item Category Code, and you can see all parent categories above it by following the Parent Category field. This means a single item can be classified as “Kitchenware → Cookware → Non-Stick Cookware” all in one clean hierarchy, rather than being locked into a two-level structure.

Additionally, Item Categories now support Item Attributes, which include detailed properties like material, color, size etc. . This gives you much more control over how you classify and search for items.

3. What Happens During Migration

Microsoft runs two automatic procedures during the upgrade from older versions to Microsoft Dynamics 365 Business Central Spring 2019 version:

LOCAL PROCEDURE UpdateItemCategoryPostingGroups@3016();
    VAR
     UPGItemCategory@1001 : Record 104098;
     UPGItem@1002 : Record 104067;
     UPGNonstockItem@1003 : Record 104073;
     TempItemTemplateCode@1005 : Code[10];
    BEGIN
      IF NOT UPGItemCategory.FINDSET THEN
       EXIT;

      REPEAT
       UPGItem.SETRANGE("Item Category Code",UPGItemCategory.Code);
       UPGNonstockItem.SETRANGE("Item Category Code",UPGItemCategory.Code);
       IF (NOT UPGItem.ISEMPTY) OR (NOT UPGNonstockItem.ISEMPTY) THEN BEGIN

      CreateItemTemplateFromItemCategory(UPGItemCategory,TempItemTemplateCode);
        ModifyNonStockItemTemplateCode(UPGNonstockItem,TempItemTemplateCode);
       END;
      UNTIL UPGItemCategory.NEXT = 0;
     END;

LOCAL PROCEDURE CreateItemCategory@1053(ProductGroup@1000 : Record 723);
    VAR
     UPGItem@1003 : Record 104067;
     ItemCategory@1001 : Record 5722;
     Item@1004 : Record 27;
     NewItemCategoryCode@1002 : Code[10];
    BEGIN
     NewItemCategoryCode := GetUniqueItemCategoryCode(ProductGroup);

     ItemCategory.INIT;
     ItemCategory.Code := NewItemCategoryCode;
     ItemCategory."Parent Category" := ProductGroup."Item Category Code";
     ItemCategory.Description := ProductGroup.Description;
     ItemCategory.INSERT;

     UPGItem.SETRANGE("Item Category Code",ProductGroup."Item Category Code");
     UPGItem.SETRANGE("Product Group Code",ProductGroup.Code);
     IF UPGItem.FINDSET THEN
      REPEAT
       Item.GET(UPGItem."No.");
       Item."Item Category Code" := NewItemCategoryCode;
       Item.MODIFY(TRUE);
       UpdateItemCategoryCodeOnLinesRecords(UPGItem,ItemCategory);
      UNTIL UPGItem.NEXT = 0;
     END;

CreateItemCategory() Procedure: Creates a new Item Category in the new system for each Product Group in the old system. It sets the parent category to whatever was assigned in the old system, then reassigns all items that used that Product Group to point to the new Item Category.

UpdateItemCategoryPostingGroups() Procedure: Preserves the posting group defaults that were attached to Item Categories. If items reference a category, it creates an Item Template with the same posting defaults. This ensures that new items created after migration still get the correct posting setup.

The key point about procedures: they simply copy your data as it exists. They do not validate information, they do not warn you about missing data, and they do not attempt to fix problems. If a Product Group had no parent category defined in the old system, the new Item Category will also have no parent after migration.

4. Data Quality Problem: Missing Parent Categories

The most common issue encountered during migration is incomplete parent-child relationships. Many items may have a child Product Group Code assigned, but the Product Group itself has no parent category defined.

Here is an example: An item has Product Group Code = “CODE-CHILD”, but that Product Group has no parent category set. When the migration runs, the system creates “CODE-CHILD” as a new Item Category, with no parent assigned(‘’). After migration, reports and business logic that depend on knowing the parent category will fail. They will skip records or show incorrect information.

4.1 How to Fix Missing Parent Data

If you discover during testing that items lack proper parent category assignments, you have two options:

• Assign all orphaned Product Groups to existing or newly created Parents. This is straightforward if you have fewer than 100 items with missing parents and not a lot Item Ledger Entries, where the Item Categories are mainly used.
• If you have many more, use a script or tool to assign them in bulk based on naming rules (for example, all Product Groups starting with “CHILD” belong under parent “PARENT”). For example, a simple script for updating Item Categories table:
  UPDATE [Item Category]
  SET [Parent Category] = ‘PARENT’
  WHERE [Code] = ‘CHILD’;
  However, all of the entries in Item Ledger Entries table, that were mismatched because of empty parent or the child becoming a parent, should also be updated. After checking in the OLD database what item ledger entries should be updated from:
  SELECT
  [Entry No_]
  FROM [Item Ledger Entry] ile
  WHERE ile.[Item Category Code] = ‘PARENT’;Fix them in NEW database:
  UPDATE [Item Ledger Entry]
  SET [Item Category Code] = ‘CHILD’
  WHERE [Entry No_] IN (1001,1002,1003);

4.2 Project Example

In one migration project, a custom sales report originally filtered items directly by Item Category Code = X1, X2, X3 (previously Product Group–based logic). After migration, the report started using the new Item Category hierarchy, where categories became child categories under parent categories X1, X2, and X3. To preserve the original reporting behaviour, the report was modified to evaluate the Parent Category instead of the item’s direct category code. Records whose parent category was not X1, X2, or X3 were skipped. This change ensured that all descendant categories remained included in the report after the Product Group → Item Category migration and aligned the custom logic with Business Central’s hierarchical category model. This was done with a simple code, added in OnAfterGetRecord() trigger:
ItemCategory.SetFilter(Code, “Item Ledger Entry”.”Item Category Code”);

if ItemCategory.FindFirst() then
ParentCategoryCode := ItemCategory.”Parent Category”
else
ParentCategoryCode := ”;

if (ParentCategoryCode <> ‘X1’) and
(ParentCategoryCode <> ‘X2’) and
(ParentCategoryCode <> ‘X3’) then
CurrReport.Skip();

5. Data Quality Checklist Before Migration

Before migrating from Product Group Code to Item Category Code, verify that your data meets these requirements:

1. Complete Hierarchy Structure: Every Product Group Code must have a defined parent category. Review each Product Group and ensure the Parent Item Category Code is filled in. Assign parents to any orphaned groups before migration.
2. Consistent Category Naming: Ensure that category codes and names are consistent and meaningful. If the old system has duplicates like “CHILD” and “CHILD-1” serving the same purpose, consolidate them before migration. This prevents confusion after migration when reports filter by Item Categories.
3. Correct Parent Mapping for Critical Items: Identify items used in specific reports, pricing rules, or posting logic, and verify that their Product Groups map to the correct parent categories. This prevents missing or misclassified items after migration.

6. Summary: Product Group to Item Category Migration Checklist

The migration from Product Group Code to Item Category Code is an automatic part of the upgrade process to Business Central. During migration, Product Groups are converted into Item Categories, existing item assignments are updated, and category-related posting defaults are preserved through Item Templates.

The migration process itself does not validate or enrich your data. It simply converts the existing structure into a new hierarchy model. As a result, any issues that exist in the current Product Group setup, such as missing parent categories, duplicate classifications, or inconsistent naming, will be carried forward into Business Central.

Because Item Categories now support hierarchical classification and are often used in reporting, filtering, integrations, and business processes, it is important to review and clean the Product Group structure before migration. Ensuring that parent-child relationships are complete and categories are consistently maintained will help avoid misclassified items, reporting inconsistencies, and additional cleanup work after the upgrade.