Industrial IoT Solution Selection: Check Service Availability Before Reusing an Architecture

An industrial reference architecture can still explain a useful data flow after one of its services stops accepting customers or stops operating entirely. Before pricing a new gateway solution, verify the availability of each required capability for the actual deployment account. A diagram that worked for an existing installation does not establish that a new project can obtain the same components.

This review concerns platform selection, not permission to change a running plant. The examples below were checked against AWS documentation on October 19, 2026. They illustrate two materially different lifecycle conditions that should lead to different engineering decisions.

Two distinct service lifecycle cases, enrollment restriction and discontinued destination, feed a capability-level replacement assessment.
Original conceptual engineering diagram. Proposed review method, not a measured result.

Separate restricted enrollment from discontinued operation

The SiteWise Data Processing Pack availability notice says that the feature is unavailable to new customers while existing customers can continue using it in maintenance mode. It explicitly distinguishes that feature from AWS IoT SiteWise and the Edge data collection pack, which remain available.

The SiteWise processor component documentation identifies November 7, 2025 as the new-customer cutoff. Its continued configuration documentation is therefore not proof that a newly established customer can adopt the processor-based architecture. Confirm account eligibility through the normal vendor channel before making it a dependency in a proposal.

AWS IoT Analytics is a different case. The Greengrass export documentation states that the service was discontinued on December 15, 2025 and that Stream Manager exports to its channels no longer function. Increasing retries or repairing a firewall will not restore a destination that the vendor has discontinued.

Describe capabilities before naming replacements

Write down what the old architecture actually supplied: collection from equipment, local transformation, offline visualization, storage, cloud ingestion, scheduled calculations, and application queries. Assign each function an execution location and an owner. This exposes gaps that disappear when a drawing labels everything as one analytics box.

For example, moving exported records to object storage may preserve a path for storing data, but it does not establish an equivalent calculation schedule, query API, local dashboard, or permission model. Those requirements need their own implementation and acceptance criteria. Treat the destination change as one part of a design, rather than as proof that the entire solution has migrated.

For the processing-pack change, AWS lists open-source pipelines, partner integrations, and MQTT-enabled gateways among migration options. Evaluate their fit to the required local and cloud functions. The existence of an alternative is not evidence that it reproduces a specific plant's behavior without additional integration.

Compare a new deployment with an existing installation

Consider a hypothetical manufacturer with a functioning installation and a proposed second factory under a new customer account. The first factory needs a continuity assessment: installed versions, permitted continued use, operational dependencies, and a justified transition plan. The second factory needs an eligibility assessment before the old bill of materials is copied.

Do not make the live factory a test of whether the proposed replacement works. Build a separate evaluation path using approved representative data. Compare the functions that operators actually depend on, including behavior during loss of cloud connectivity. Any final cutover needs site approval and a recovery plan appropriate to that installation.

Inspect configuration without deleting evidence

For a Greengrass system that still names an IoT Analytics export destination, inventory the configured stream, destination, retained data, and consuming applications. AWS documents updating the stream's export definition to omit that destination. Plan the replacement export and its downstream processing before making a controlled configuration change; this article does not prescribe deleting and recreating a stream containing useful data.

The selection result should be explicit: which features remain usable by the intended customer, which require a replacement, and which expected behaviors are still unverified. Keep the dated vendor references with the proposal. Recheck them before procurement or commissioning, because a supported architecture is a current dependency decision, not a permanent property of an old tutorial.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *