Project Rome is Microsoft's name for a family of cross-device capabilities, including Windows Remote Systems and Microsoft Graph activities. Microsoft still publishes Project Rome documentation, but parts of the wider stack, including Microsoft Graph notifications integration, are explicitly deprecated.
Do not treat Project Rome as one product with one retirement date. Check the status of the exact API you plan to use.
What Project Rome was trying to solve
Project Rome was designed around a simple problem: people move between devices while their task remains the same.
Microsoft's Project Rome overview groups the platform into cross-device programming APIs and underlying infrastructure. Documented scenarios include discovering remote systems, launching an app or URI on another device, communicating with a remote app service and representing user activities.
That historical architecture explains several Windows APIs which are still documented today.
The Windows Remote Systems route
For Windows applications, the Windows.System.RemoteSystems namespace provides APIs for discovering and interacting with remote systems. Microsoft's current remote-device discovery guide uses RemoteSystem.RequestAccessAsync, RemoteSystem.CreateWatcher and watcher events.
A supported design must account for:
- the Windows app model and API contract you target;
- user consent and cross-device settings;
- device discovery filters;
- authentication and account context;
- devices appearing, changing or disappearing;
- the target app or URI being unavailable.
Discovery is not a guarantee that an action will succeed. Handle denied access, no results, disconnects and unsupported targets in the user experience.
The Microsoft Graph boundary
Microsoft Graph still documents Project Rome activity resources, including userActivity and activityHistoryItem. These APIs are about representing and recording activity, not a general device-control channel.
Separately, Microsoft's page for Graph notifications integration is marked deprecated. An old sample that combines activities, notifications and device relay can therefore contain a mixture of current and retired components.
This is why a namespace replacement is not a migration plan.
How to assess an old Project Rome application
Create an inventory before editing code:
- List every Project Rome package, namespace, Graph endpoint and permission.
- Link each item to current Microsoft documentation.
- Record whether it is supported, deprecated, preview or no longer documented.
- Identify the user outcome: launch, resume, share, notify, discover or control.
- Decide whether Windows-native APIs, ordinary deep links, cloud state synchronisation or another supported service now fits better.
- Test the smallest supported path in a disposable application and tenant.
Do not promise a fixed migration duration. The work depends on authentication, platform targets, app packaging, background execution and the discontinued components in the original design.
Permissions and security
Remote discovery and launch features cross a device boundary. Request only the access needed, make the target clear to the user and do not silently accept remote commands.
If a sample auto-accepts a session or hard-codes an account assumption, treat that as demonstration code rather than a production pattern. Add identity checks, user confirmation, failure logging and a way to disable the feature.
What this article proves
The linked Microsoft pages prove that Project Rome documentation and Windows Remote Systems APIs remain published, and that Graph notifications integration is deprecated. They do not prove that a particular legacy application will compile, authenticate or pass store certification.
Build a minimal compatibility test against the exact SDK, Windows version and identity model you support.
For practical Microsoft platform architecture discussions, join the SharePoint & Teams Admins Space.