Migrate from Digit to Infor CloudSuite Corporate

DIGIT's Citizen entity is the central cross-module identifier linked to property records, trade licences, complaints, and FSM service requests. Infor CloudSuite Industrial has no native citizen entity. We map each DIGIT Citizen to an Infor Address record (ADDRE5) and create a corresponding Business Partner (OC BPA) with the BP type set to Government or Citizen via a custom BP extension table. The original DIGIT citizen identifier is stored in a custom field on the BP record for cross-reference and audit. All module-specific records (PT, TL, PGR, FSM) reference this BP via the resolved citizen identifier.

DIGIT PT stores property records with boundary definitions, assessment values, owner associations, and payment histories. Infor CloudSuite does not have a native property management object. We map property records to a combination of Address (property location), Item records (for assessment and billing units), and a custom PT_PROPERTY extension table that stores PT-specific fields including boundary codes, assessment cycle, exemption flags, and demand register references. Owner associations resolve through the citizen-to-BP mapping established in Step 1.

DIGIT TL records hold business details, licence categories, application status, and issuance history linked to a Citizen. We map these to Infor CloudSuite Business Partner Modification records (OC BPMDT) with category codes translated from DIGIT's TL licence type taxonomy to Infor's BP Modification type codes. Application status and issuance history migrate as modification date-effective records against the BP. If the target Infor edition lacks BP Modification support, we create a TL_LICENCE custom object with all TL-specific fields and a lookup to the resolved Business Partner.

DIGIT PGR manages citizen complaints with workflow states, department assignments, and resolution tracking. Infor CloudSuite Industrial does not have a native citizen service module. We map PGR grievances to Infor Case records (if Service Cloud is licensed) or to a FSM_WO custom work order table with a complaint category field. Each grievance's status, timeline events, and action history migrate as WO operations or Case history entries. The PGR citizen identifier resolves to the Business Partner created in Step 1 so that complaint records are linked to the correct citizen.

DIGIT FSM handles sanitation, drainage, and desludging service requests with routing, field worker assignment, and completion records. Infor CloudSuite Industrial includes FSM capabilities as part of the LN suite. We map FSM service requests to Infor FSM Work Orders (SFO WO) with routing, asset association, and completion data translated to Infor's WO operation structure. Open FSM requests with active assignment require careful OwnerId resolution against the DIGIT HRMS employee mapping to ensure field workers are provisioned as Infor users before WO import.

DIGIT HRMS stores employee records, roles, department assignments, and leave balances. We map these to Infor CloudSuite Employee records. Role-permission mappings are deployment-specific in both systems and do not migrate automatically. We preserve role names and department assignments in custom fields on the Infor Employee record and flag that permission sets require manual validation against the Infor role model post-migration. Leave balance data migrates to the HRMS module if the target Infor edition includes HRMS, or to a HR_LEAVE_BALANCE custom table.

DIGIT demand registers (PT billing, FSM service invoices) store financial records with status flags across multiple modules. We split by module: PT demand records map to Infor AR Invoice entries linked to the Property BP; FSM invoices map to FSM Work Order cost entries. Demand register status (paid, pending, overdue) migrates to Infor's Invoice status field. Open invoices require careful date-based filtering to ensure the cutover date captures all outstanding receivables in the migration window.

DIGIT deployments use JSON/CSV localisation files for multi-language labels, region-specific business rules, and module configurations. Infor CloudSuite manages localisation through Infor OS Configuration Management rather than external files. We extract the DIGIT localisation files, map each locale key to its corresponding Infor OS configuration entry, and apply the mappings during the Infor CloudSuite configuration phase. Multi-language citizen-facing labels require Infor OS language pack activation in the target deployment.

Because DIGIT modules maintain partial data separation, a single citizen may appear across PT (property owner), TL (business licensee), PGR (complainant), and FSM (service requestor) with different internal IDs in each module. We build a Citizen Cross-Reference table during extraction that maps each module-specific identifier to the canonical citizen UUID and the resolved Infor Business Partner ID. This reference table is loaded before any module records and is used to link all cross-module associations in Infor CloudSuite.

DIGIT PT and FSM modules use boundary definitions (administrative area, zone, ward) for jurisdiction and routing. Infor CloudSuite Address supports region codes but not hierarchical boundary structures. We map DIGIT boundary levels to a custom BOUNDARY_HIERARCHY table with parent-child relationships matching the source hierarchy, and link boundary codes to Infor Address Region fields for geospatial queries.