Migrate from Enterprise Operating System (EOS) to Microsoft Dynamics 365 Business Central

EOS Rocks migrate to Microsoft Project Operations Goals or Tasks depending on the D365 module in scope. Each Rock carries owner, due date, status, and milestone sub-tasks. We preserve quarterly cycle context by tagging each migrated record with a custom period field (Q1-Q4 + Year) so that the quarterly cadence does not flatten into a flat task list. Milestone sub-tasks from EOS migrate as child Tasks linked via the Parent Task lookup. The Rock status (On Track, Behind, Off Track) maps to a custom picklist field rather than a native D365 status value.

Issues raised during EOS Level 10 meetings follow the IDS workflow (Identify, Discuss, Solve). We map Issue status (Identified, In Discussion, Solving, Solved) to D365 Task Status values (Not Started, In Progress, Completed), preserving the owner, raised date, and resolution notes. Issues that were solved in EOS receive a Completed status and a resolution timestamp. Issues still open at migration time carry forward with their current IDS stage intact.

Action items extracted from EOS Level 10 meeting notes migrate as standalone D365 Tasks with the original owner, due date, and meeting reference date preserved. Meeting scores (1-10 grading of each of the ten agenda items) migrate as custom numeric fields on the Task record for the parent meeting reference entity. This preserves the structured meeting output without requiring a native Level 10 equivalent in D365.

The annual V/TO document in EOS One stores vision, 3-year picture, 1-year picture, Rocks, and CAP cards as a structured document. D365 has no native V/TO equivalent. We export the V/TO as a composite record in a custom D365 entity (VisionTractions__c) with section fields for vision statement, 3-year picture, 1-year picture, and year Rocks, linked to the corresponding migrated People records. Alternatively, for organizations preferring document-centric storage, we export the V/TO to a SharePoint library connected to D365 and link it to the Org record.

EOS Scorecard rows contain metric name, unit, value, and weekly measurement date. We migrate Scorecard entries as structured KPI records in a custom D365 entity with fields for metric_name, unit, value, measurement_date, and period_tag (Week number + Year). For organizations licensing Business Central or Finance, these custom KPI records can be exposed in Power BI dashboards. We preserve the full time-series history so that quarterly trend reporting can begin immediately after go-live.

EOS People records contain seat assignments, accountability chart position, and CAP ratings (Communicator, Asset, Passion) as free-text fields. We map People to D365 Contacts for organizations using Sales or Business Central, or to Employee records in Human Resources for organizations using that module. The CAP ratings migrate as three separate custom fields (cap_communicator__c, cap_asset__c, cap_passion__c) with the original free-text rating preserved. Seat assignment and accountability chart position migrate as custom fields on the Contact or Employee record.

CAP cards in EOS One store individual Communicator, Asset, and Passion ratings with free-text commentary for each dimension. While CAP ratings are technically fields on People, CAP card commentary often contains substantive feedback that warrants dedicated record treatment. We create a custom CAP_Cards__c entity linked via Lookup to the corresponding Contact or Employee, with fields for rating_type, rating_value, and free_text_comment. This prevents the CAP card narrative from being lost in a generic notes field.

EOS Issues tracked through the IDS workflow migrate to D365 Tasks by default. For organizations that used EOS Issues to track customer-facing or service-level problems (rather than internal execution blockers), we offer mapping to Cases in the D365 Customer Service module, where the IDS workflow stages map to Case Status and Resolution fields. The mapping choice is confirmed during scoping based on how the customer actually used the Issues object in EOS.

EOS Process documentation is stored as structured free-text SOPs in EOS One. We export Process records as text blobs to a custom D365 Process_Documentation__c entity. Where the customer used the EOS Process Builder tool to create structured process flows, we export the process hierarchy as a structured JSON and store it in SharePoint Online, connected to D365 via the native SharePoint integration. We flag that processes built as free-text SOPs cannot be automatically reconstructed as typed D365 records and will require manual entry or a documentation migration tool.

EOS company settings include org name, fiscal year, and team hierarchy as defined in the V/TO accountability chart. We map these to a custom D365 Organization__c entity with fields for company_name, fiscal_year_start, and team_structure (as a hierarchical custom field or JSON blob). The team hierarchy is preserved as a parent-child relationship structure rather than flattened, so that D365 Project Operations or Business Central can display reporting lines correctly.

EOS Org Checkup stores periodic team health survey results aligned to the Six Key Components, with numeric scores and free-text commentary. We export numeric scores as structured records in a custom D365 Org_Checkup__c entity with fields for component_name, score_value, max_score, survey_date, and free_text_comment. The full time-series of checkup results migrates so that the customer can build Power BI trend reports on organizational health post-migration.

EOS One integrations with calendar, email, and Drive tools do not have a documented REST API, so there are no integration connection states to migrate. We document every active EOS integration (calendar sync, email sync, Drive folder linkage) as a written inventory with the connection type, the connected service, and the recommended D365 or Power Platform equivalent. The customer re-establishes these connections post-migration: D365 Calendar sync connects via Exchange or Outlook integration; Drive documents migrate to SharePoint Online libraries connected to D365; Power Automate flows are rebuilt separately as part of the automation handoff inventory.