Migrate from ServiceTracker to monday CRM

ServiceTracker's CMMS schema has no native CRM equivalent — data must be decomposed into multiple Monday boards

ServiceTracker stores customers, work orders, assets, contracts, and inventory in a single CMMS object graph with foreign-key relationships. Monday CRM does not have a single equivalent object — it has People (contacts), Deals (revenue), and free-form boards for everything else. FlitStack AI decomposes the ServiceTracker entity graph into four or five Monday boards (Service History, Assets, Contracts, Inventory, Locations) connected by Monday's connect-board columns. This decomposition is a design decision, not an automatic mapping, and different board structures produce different reporting outcomes in Monday. We deliver the board design plan before migration commits any data.

Monday CRM API daily call limits constrain migration load pacing on lower plans

Monday CRM enforces daily API call limits that vary by plan: 200 for Free/Trial, 1,000 for Basic/Standard, 10,000 for Pro, and 25,000 for Enterprise. ServiceTracker exports with 50,000+ work orders and associated line items can generate hundreds of thousands of Monday API calls when account for board reads, column metadata, and item inserts. Migrating on a Basic plan risks hitting the daily cap mid-run, requiring第二天 resumption. We assess the record volume and recommend a plan tier or pacing strategy before starting — teams with large datasets should upgrade to Pro or use Monday's CSV import for bulk initial loads followed by API delta syncs.

Connect-board column linking requires destination boards to exist before items are created

Monday CRM's connect-board columns create relational links between items across boards — for example, linking a work order item on the Service History board to a People record and an Asset item. These links can only be established after both the source item and the destination item exist in Monday. In migration terms, this means the order of operations matters: People must migrate first (for customer links), Assets must migrate second (for asset links), and Work Orders must migrate last (after all dependency records exist). FlitStack sequences the migration with this constraint, but teams that pre-create boards in Monday without understanding this dependency chain will encounter orphaned links.

Custom dropdown fields in ServiceTracker require Monday option-set creation before migration

ServiceTracker custom fields of type pick-list (priority codes, service categories, permit types, technician skill tags) store a fixed set of values. Monday CRM dropdown columns also use a fixed option set, but the options must be created in the Monday board before any item with that column can be saved via API. If the ServiceTracker pick-list has 40 values and Monday has 5, the remaining values are either dropped (data loss) or remapped to an 'Other' option. FlitStack generates a value-mapping table for every ServiceTracker pick-list field before migration, showing exactly which values map, which merge, and which require a new Monday option to be added.

Automation Recipes and dispatch workflows do not migrate and require Monday-native rebuild

ServiceTracker automation rules — such as auto-assigning work orders based on technician skill, triggering notifications on status changes, or routing based on site location — are stored in ServiceTracker's rule engine and have no equivalent in Monday CRM. Monday's automation system uses Recipes (no-code trigger-action pairs) which must be rebuilt manually after migration. FlitStack AI exports a list of every active ServiceTracker automation rule as a plain-English rebuild reference, but the implementation is a Monday-admin task. Teams should plan a two-week parallel run where both systems are live so ServiceTracker's automations continue running while Monday Recipes are built.