From SAP Work Manager to SAP Service and Asset Manager

SAP Work Manager runs on Agentry, a platform in maintenance mode. SAP Service and Asset Manager is its successor: same functional family, but built on the Mobile Development Kit and deployed from SAP BTP. All functional evolution —and medium-term support— now lives in SSAM.

Far more than teams usually fear. The backend is the same world: work orders, notifications, functional locations, equipment, materials and measurement points remain standard SAP PM and CS objects.

• Master data and the process model, untouched
• User profiles and work assignment logic
• Operational knowledge: what the technician does, and in what order

Everything above the backend. Logic written in Agentry Editor does not migrate: it is rebuilt with MDK metadata, OData services and add-on extensions. That's the bulk of the effort, and where a four-month project becomes a one-year one.

• Custom Agentry screens and flows
• Business rules embedded in the old app
• Custom integrations and attachment sync
• Printing, signature and photo capture, where customised

The most expensive mistake is replicating the old app screen by screen. Before touching code, find out what's genuinely used.

• Inventory customisations and measure real usage
• Separate what technicians touch daily from what nobody opens
• Pilot standard SSAM with one small crew
• Extend with MDK only where the standard breaks the process
• Roll out plant by plant or crew by crew — never big bang

We see these in almost every project we inherit mid-flight.

• Migrating dead customisations because nobody audited them
• Leaving offline behaviour and data volume until the end
• Testing only in the office, on wifi, with demo data
• Training technicians on go-live day instead of before

With a clean standard scope and master data in order, three to four months to the first group in production. With heavy inherited customisation, eight to twelve. The difference is rarely technical: it's how many customisations you decide to drop.