Keep one ops layer across ancient and brand-new images

Amber Field Systems inherits decade-old farm gateways and ships Ubuntu 24.04 sampling nodes in the same programme. Solstice building controllers tell a similar story. An ops agent that only chases “current Python” breaks half the estate - or forces two control planes.

Without Dataplicity

Legacy units are abandoned or hand-SSH’d. Modern rollouts wait on a rewrite. Nobody shares one inventory - and Amber cannot tell which regions still check in on the old image.

With Dataplicity

1. Use the dual install path (curl | sudo python) that works when the system python is 2 or 3.
2. Install the current rescue agent on both cohorts. Packaging requires Python 2.7 or newer. The build and test matrix covers 2.7, 3.5–3.7, and 3.9–3.12 (including Ubuntu 24.04 / Python 3.12), so one organisation inventory covers old and new images.
3. Confirm check-in for both cohorts under one organisation inventory - including Amber’s sparse field windows when devices finally wake.
4. Qualify the exact image you ship against that matrix. See Dataplicity agent for the full rescue and supervisor requirement tables.

Outcome

One ops layer across mixed-age field reality - without abandoning the farm cabinets that still earn their keep.

Next

• Connect your first device
• Dataplicity agent
• Supported operating systems
• Agent lifecycle

Related: Illustrative customers, Field advantages, Keep your runtime