Migrate from Wiise to Microsoft Dynamics 365 Business Central

Wiise Customer master records (name, address, contact details, payment terms, credit limits) map directly to Business Central Customer or Finance and Operations CustCustomerGroup. Custom Fields on Customer pages migrate as typed fields in the destination. Customer currency and payment terms resolve to the destination's payment term codes. The dedupe key is Customer Number or email.

Wiise Vendor cards follow the same structure as Customer cards. Vendor-specific dimensional tags for cost-centre assignment migrate to destination dimension defaults on the Vendor record. Purchase currency, GST vendor type, and payment terms map to destination payment term codes. Custom Fields on Vendor pages migrate as typed fields or JSON-encoded blobs for re-injection.

Wiise Items (stock items, non-stock items, services) map to Business Central Item or Finance and Operations Released Product. Unit cost, inventory posting groups, and warehouse location assignments migrate directly. Wiise's 2 decimal-place limit on custom Item fields means any precision beyond 2 decimals is flagged in the pre-flight report before mapping. Item type (Inventory vs Service vs Non-Stock) maps to the destination Item type enum.

Wiise uses a dimensional chart with cost-centre, department, and location tags on every posting. Account codes and names migrate 1:1 to the destination Chart of Accounts. Dimensional assignments require field-level mapping per tag type: Wiise cost-centre maps to Business Central Default Dimension or Finance and Operations Financial Dimension. We flag every instance where a dimensional tag cannot be represented natively and propose a custom dimension or tag-group configuration in the destination before import.

Outstanding purchase invoices are migrated as open vendor ledger entries. We preserve invoice date, due date, remaining amount, and currency. Full invoice line history migrates on request but the default scope is open items only. Wiise AP dimension tags on the vendor record are applied as default dimensions on the open entries. Historical posted invoices that are fully paid do not migrate unless the customer requests a full transaction history carry-forward.

Outstanding sales invoices migrate as open customer ledger entries with invoice date, due date, remaining amount, and currency preserved. Dimension tags from the Wiise Sales Header are applied as default dimensions on the migrated entries. Partial payments are represented as credit memos or partial payments on the original invoice reference. Full invoice history migrates on request but defaults to open items for standard scope.

Wiise Jobs support task-level work breakdown, resource assignments, and billing. We map Job headers and tasks directly. Job-specific dimensional tags migrate as custom fields to avoid schema conflicts in the destination. Work-in-progress balances and unbilled revenue migrate as Job ledger entries with posting date set to the migration go-live date for open jobs. Historical job cost journals migrate on request.

Employee records (name, position, department, employment status, HR metadata) migrate for both active and terminated employees. Where the destination HRMS uses different effective-dating semantics, we set the effective date to the migration go-live date for active employees. Employee custom fields migrate as typed fields. The destination's employee number or Azure AD user ID is resolved against the Wiise employee record at migration time.

Fixed Asset records include acquisition date, cost, depreciation method, book value, and location. We preserve depreciation schedules as-is and flag any assets still under depreciation at migration date so the destination can absorb the remaining book value as an opening balance. Depreciation books and insurance policies attached to fixed assets in Wiise migrate as related records or custom fields depending on destination capability.

Wiise custom fields exist on 15 page types: Customer, Vendor, Item, Sales Header/Lines, Purchase Header/Lines, Job, Contact, Fixed Asset, Service Item, and production objects. We extract all custom field values at migration time and re-inject them as typed fields in the destination (Business Central AL extensions or Finance and Operations user-defined fields). Fields that cannot be typed directly (e.g., multi-select lists exceeding destination picklist limits) are stored as JSON-encoded text with a flag in the pre-flight report. The 2 decimal-place cap on Wiise custom decimal fields is documented per field before import.

Wiise manages multiple legal entities under one subscription with intercompany transactions. We export each entity's books as a separate company unit and include intercompany balancing entries to preserve the consolidated view. All entities to be migrated must be declared during discovery; adding an entity after extraction begins requires a separate extraction pass and risks partial data for that entity. We request a complete entity list on the discovery call.

Multiple warehouse locations in Wiise map to Location records in Business Central or Warehouse sites in Finance and Operations. Item-location quantity records (bin-level if Wiise uses bin tracking) migrate directly. Where the destination uses location-level only (no bin tracking), we aggregate quantities to the location level and flag the aggregation in the pre-flight report for customer sign-off.

Payroll in Wiise is a priced add-on with AU/NZ-specific schema (pay runs, superannuation, leave balances, employee compensation history). We scope payroll as a distinct migration workstream because it requires HR team sign-off on employee-level records and separate extraction from the core ERP schema. Pay history, leave accruals, and superannuation contribution records migrate as typed rows. BPAY and payment gateway configurations do not migrate; these require re-configuration in the destination with the customer's bank.

Wiise exposes no documented public API endpoint for retrieving attached documents (invoices, purchase orders, scanned files, images) from within the Business Central infrastructure. Binary attachments cannot be reliably extracted via the API. We ask customers to use Wiise's built-in export function to download these manually before the cutover date and store them in a SharePoint library or file share that the destination system can reference post-migration. We flag this step explicitly in the pre-migration checklist and it is the customer's responsibility to complete it before the cutover window.