Migrate from Enterprise Operating System (EOS) to Acumatica

EOS Rocks become Acumatica Project Tasks under a master Project (named 'EOS Migration Master'). Each Rock's title, description, owner, due date, priority, status, completion percentage, and created/updated timestamps map directly. Acumatica custom fields for Rocks use the Usr prefix per the Acumatica Customization Platform convention. Owner resolved by email match against Acumatica users; unmatched owners flagged before migration.

EOS Issues map to Acumatica Project Tasks using the same field set as Rocks. A tag or custom ProjectTask field (UsrEOSSource) distinguishes Issues from Rocks in Acumatica's task list so teams can filter the project view by EOS origin type. Acumatica ProjectTask's isTemplate and status fields handle open/closed state mapping from EOS issue lifecycle stages.

EOS Level 10 meeting records map to Acumatica Activities attached to the master Project. The meeting subject, date, duration, notes (as Activity details), and next-steps field carry over. Facilitator and owner resolve by email match. Acumatica Activity's startDate, endDate, category, and status fields replicate the EOS meeting structure. Meeting-generated follow-up Rocks are not automatically created — that workflow logic must be rebuilt in Acumatica's Project Management system.

EOS team members and stakeholders become Acumatica Contact records. The email field enables Acumatica user resolution for ProjectTask and Activity ownership. EOS role values require a custom Contact field (UsrRole) since Acumatica's native Contact DAC does not include a role attribute. If the team member is also a customer or vendor in Acumatica, their Contact record is created first and linked to the Customer or Vendor account.

Acumatica has no native KPI or scorecard module. Each EOS scorecard metric (name, value, goal, frequency, lastUpdated) maps to a custom field pair on the Project DAC — UsrScorecardMetricName, UsrScorecardMetricValue, UsrScorecardMetricGoal — created through the Acumatica Customization Project Editor. Custom fields use the Usr prefix and are defined in the CustObject table with XML definitions in the customization project package. Because Acumatica lacks a native KPI module, scorecard values cannot pull live from a separate calculation engine — they are static migrated values requiring manual update inside Acumatica.

The EOS V/TO is a PDF or presentation file storing organizational vision, core values, and long-term goals. Acumatica has no native equivalent — it stores vision artifacts as file attachments on Projects and Notes. We attach the V/TO document to the master Project and create a custom Project field (UsrVTODocumentAttached) to flag its presence. The content of the V/TO (vision, values, goals) does not map field-by-field; it must be reframed manually inside Acumatica's entity and Project structure by your leadership team.

EOS Organizations and Companies in the EOS People or V/TO context map to Acumatica Customer and/or Vendor accounts. If the same entity is both a customer and a vendor, it becomes two separate accounts in Acumatica's AR and AP ledgers. EOS company-level data (name, address) maps to the Customer or Vendor name and address fields. GL account assignments for AR and AP are configured inside Acumatica's Chart of Accounts and Payment Terms screens — this requires Acumatica-side planning and is not auto-populated from EOS data.

Some EOS implementations use a Pipeline or Process component to track stage-based workflow for deliverables. Acumatica has no native pipeline equivalent for Project Tasks. If EOS pipeline stages exist, we create a custom ProjectTask field (UsrEOSProcessStage) as a pick-list mapping each EOS stage name to the corresponding Acumatica stage value. Task templates in Acumatica's Project Management module can replicate stage-based workflow if your team uses structured deliverable gates.

EOS meeting participant names are linked to EOS People records. During migration, each participant resolves to an Acumatica Contact by email match. The Acumatica Activity's entity associations link each participant Contact to the Activity record. Participants without matching Acumatica users are flagged; their Contact records are created from the EOS People data before Activity migration.

EOS Rock and Issue owner fields hold a user reference (typically name and email). Acumatica ProjectTask's Owner field maps to PM.Employee — not to a Contact or User. Owner resolution happens by matching the EOS owner email to Acumatica user emails, then resolving to the corresponding PM.Employee record. If no Acumatica employee record exists for the EOS owner, their Contact record is created first, then flagged for employee provisioning before the ProjectTask is assigned.

EOS IDS (Identify-Describe-Solve) process logs and core process documentation are text artifacts stored inside the EOS tool. Acumatica has a Note object and Project attachment capability for text records. IDS logs are extracted as text and stored as Notes on the relevant Project or ProjectTask. The structured problem-solving workflow of IDS is not a native Acumatica construct — it is preserved as documentation for your team to operationalize inside Acumatica's Project and Issue management screens.

EOS files attached to Rocks, Issues, or meetings are downloaded and re-uploaded to the Acumatica Project as Project-level attachments. File size limits in Acumatica's attachment framework apply (typically 10MB per file for standard uploads). Inline images in meeting notes are preserved as attachment references. Files are associated with the ProjectTask or Activity that they documented in EOS.