Documentation

Appearance

How do we offboard from Dataplicity and preserve portability? ​

A healthy connected-product architecture should have a credible exit path.

Dataplicity should make operating the product easier, but your hardware should not become unusable merely because you stop using the platform. Keep local product behaviour, safety, and authoritative business data in systems you can continue operating independently.

Know what Dataplicity owns in your architecture ​

List the platform responsibilities you actually use:

  • device identity and outbound connection;
  • Remote Shell/support path;
  • fleet inventory/grouping;
  • logs/monitoring;
  • Device Classes;
  • streams/settings/actions;
  • class software/container delivery;
  • Customer Portal tenancy/UI;
  • Product Application records/workflows/offline datasets;
  • API integrations.

Offboarding means deciding how each responsibility is removed, replaced, or retained elsewhere.

Keep core device operation independent ​

Your product application should continue performing its essential local function without a live Dataplicity session.

Do not make Dataplicity the sole owner of:

  • safety interlocks;
  • bootability;
  • basic device configuration needed to function;
  • firmware recovery;
  • local credentials required for field servicing;
  • financially authoritative business state.

That makes both outages and vendor exit easier to reason about.

Preserve the data that matters before shutdown ​

Identify data you need to retain for contractual, operational, support, or legal reasons.

Examples include:

  • customer/site/device mappings;
  • product application records;
  • audit/activity history;
  • telemetry/history required by your service;
  • configuration state;
  • software/release inventory;
  • incident/support evidence.

Use supported exports/APIs where available. If a dataset is legally or financially authoritative, it should normally already exist in an appropriate system of record rather than only in a convenience UI.

Replace the device connection deliberately ​

If another platform will take over remote connectivity/fleet operations:

  1. install and prove the replacement on a small cohort while Dataplicity still works;
  2. verify reconnect/reboot behaviour;
  3. verify your new support path;
  4. confirm customer networking requirements;
  5. remove Dataplicity only after the replacement is proven.

Do not intentionally cut off your working management channel before the new one is validated.

Remove device-side components cleanly ​

Document how to:

  • stop/disable the agent;
  • remove packages/files according to the supported uninstall path;
  • remove Dataplicity-managed application/container components you no longer need;
  • revoke credentials/identity;
  • verify the product application still starts after reboot.

Do not delete unrelated customer application state simply because the management agent is removed.

Customer Portal replacement is a product migration ​

If your customers use a Dataplicity Customer Portal, replacing it requires more than uninstalling an agent.

Plan:

  • customer/user migration;
  • site/device ownership mapping;
  • replacement authentication;
  • product UI/data/control equivalents;
  • communication and cutover;
  • old-session/access revocation;
  • retained historical data.

Run both customer surfaces in parallel if that materially reduces cutover risk.

Product Applications need an explicit data/workflow exit plan ​

For Product Application records and workflows, identify:

  • data to export;
  • schemas/identifiers that need mapping;
  • active processes that must finish or migrate;
  • offline datasets still cached on devices;
  • commands/actions that must no longer be accepted;
  • external integrations that must be redirected.

Do not assume an in-flight workflow can be moved between systems without domain-specific handling.

Reassignment and cached data ​

When a device leaves the Dataplicity tenancy model, remove or invalidate customer-specific cached/offline data that should no longer remain on the device.

This is especially important for:

  • credentials;
  • access lists;
  • customer configuration;
  • entitlement data;
  • private site information.

A device transfer/offboarding runbook should include local data cleanup, not just cloud account deletion.

Test exit before you need it ​

A useful production-readiness exercise is to offboard one staging device:

  • export required metadata;
  • replace/disable the Dataplicity support path;
  • reboot;
  • verify product function;
  • verify the old Dataplicity access is gone;
  • verify customer-specific data has been handled correctly.

This exposes hidden dependencies while you still have time to fix them.

Avoid artificial lock-in in your own integration ​

Use stable product/domain identifiers that do not exist only because Dataplicity assigned them. Keep your own serial numbers, customer IDs, transaction IDs, and domain identifiers where they are meaningful.

That makes integration, migration, and reconciliation easier in either direction.