Changing a temperature monitoring provider creates a question that is easy to leave until the end: what happens to the records already in the system?
A downloaded spreadsheet may contain readings while leaving out the asset history, alarm actions or calibration records needed to interpret them. A PDF may be readable but difficult to search across a large equipment fleet. Continued access to an old portal may be useful, but only if its availability and terms are understood.
Before closing an account, agree how your organization will retain, retrieve and understand its monitoring records. Treat that as a defined part of the transition, with an owner and acceptance checks. The right time to test an exit process is while the existing provider and system are still available.
What records will your team need after the switch?
Begin with the questions people may need to answer. Which equipment held a particular material during a specified period? What readings were recorded? Was an alarm raised? Who responded? Which sensor was installed at the time?
Use those questions to identify the records within your required scope. Depending on the application and system, that may include measurements, asset identifiers, sensor assignments, alarm histories, acknowledgements, configuration changes, calibration documents and relevant reports. Some of that information may be held in a separate quality or maintenance system rather than the monitoring platform.
Map where each record type lives and who controls it. Do not assume that a single export command includes everything your team relies on. Equally, do not copy unrelated personal or operational information simply because it is available. Define the purpose, access arrangements and retention requirements for the archive with the responsible owners.
What should you ask the current provider to demonstrate?
Request a sample export from a known asset and time period. Choose a period that includes an event your team can recognize, such as a documented alarm or sensor replacement. Compare the export with the information available in the system while both are accessible.
Ask which formats are available, what each contains and what limitations apply. Discuss whether large exports need to be split by date, location or asset. Identify any delivery lead time, fees or support work needed to obtain the agreed records before you set the cancellation date.
If the provider offers an application programming interface, clarify which record types it exposes and how access is controlled. An API may be useful, but its existence does not prove that every required record is available through it. A complete, usable archive is the outcome; the delivery method is one part of achieving it.
These questions belong in a monitoring provider evaluation as well as an exit project. Ask a prospective provider to explain its export and retention arrangements before signing a new agreement.
How will you preserve the meaning of each reading?
Keep stable identifiers wherever possible. A familiar display name may have changed over time or may be reused at several sites. Record the relationship between site, asset, sensor and measurement channel so that a future reviewer can identify what a file represents.
Check the units and timestamp conventions. Establish whether exported times use UTC, a local offset or another documented convention, and how daylight-saving changes are represented. Avoid silently converting timestamps or changing units without preserving the original information and documenting the transformation.
Retain a description of the exported fields and any status codes. A blank value, an unavailable reading and an out-of-range observation should not become indistinguishable because someone removed a column during cleanup. Preserve the original delivered files alongside any working copies used for analysis.
An example illustrates the issue: a column labeled “Temperature” and a file named “Freezer 1” may look sufficient today. Two years later, a reviewer may need to know which site it belonged to, which probe recorded it and whether the time shown was local. The export should not depend on someone’s memory to answer those questions.
How can you check that the archive is usable?
Create an acceptance checklist before requesting the final export. Record the assets, date ranges and record types expected. Compare what arrives with that inventory, and investigate missing files or unexplained differences before approving completion.
Where appropriate, compare counts and date boundaries between the source system and the export. Differences need interpretation: system settings, event-based records or recorded interruptions may affect what is expected. Do not fill gaps with invented readings or assume that every discrepancy is harmless.
Test retrieval with a person who did not prepare the files. Give that reviewer a specific task, such as finding the readings and alarm response for a named asset during a defined period. Check whether the reviewer can identify the source, understand the timestamps and locate the related documents without returning to the old portal.
Keep a record of the checks performed, issues found and their resolution. Technical controls such as file checksums can help detect later changes, but they do not prove that the original export was complete. Completeness and preservation are separate questions.
Must historical data be imported into the new platform?
Not necessarily. Your team may retain a controlled, retrievable archive while the new platform holds records from the agreed transition point. The appropriate arrangement depends on your requirements, the available formats and the capabilities of the systems involved.
If importing historical data is proposed, ask what context will survive the import. Measurements may be transferable while original audit history or electronic approvals are not. Imported information should be identifiable, and the original records should remain available as required by the approved plan.
For QC’s platform, consult the MySirius User Guide in our Resources library for day-to-day reporting and archive guidance. Confirm the available functions against your installed version and project requirements. A user guide is a reference for operating the platform, not a guarantee that another provider’s records can be imported.
Avoid assuming that every file format or third-party sensor is compatible with a new system. When discussing MySirius monitoring software, bring representative exports and your required use cases. Confirm the supported approach explicitly rather than treating historical-data migration as an automatic feature of a replacement project.
The physical rollout is a related but separate task. QC’s data logger replacement plan addresses assessment, pilot work and transition planning. This checklist focuses on the records that must remain understandable after the old system is retired.
Who should approve the archive and account closure?
Assign a business owner for the records, a technical owner for storage and access, and an appropriate reviewer for the acceptance checks. In regulated operations, involve the quality team in the decisions that affect the required record lifecycle and change-control process.
Define who can access the archive, how access will be maintained when staff change and how recovery will be tested. An export held only on the project manager’s laptop is not a durable organizational handover. Document the storage location and retrieval instructions where authorized staff can find them.
Coordinate account closure with ongoing monitoring. Preserving historical records does not establish that the new system is ready to take responsibility for live measurements and alarms. Keep those acceptance decisions separate and ensure the planned closure does not remove monitoring coverage that is still needed.
If the transition affects a qualified system or its required records, discuss the appropriate validation and change-control work before execution. The work should reflect the actual change and agreed requirements, rather than a generic promise that all migrations are equivalent.
What belongs on the vendor exit checklist?
Use the following questions at the project review. Record an owner and evidence for each answer rather than relying on a verbal “done.”
| Review question | Evidence to retain |
|---|---|
| Which assets, periods and record types are included? | Approved scope and record inventory |
| What do the provider’s exports contain or omit? | Sample files, field descriptions and documented limitations |
| Are timestamps, units and equipment identities understandable? | Interpretation notes and checked examples |
| Have missing or inconsistent records been investigated? | Reconciliation findings and their disposition |
| Can another authorized person retrieve a known event? | Retrieval test and reviewer result |
| Is the archive protected and recoverable? | Access arrangements, storage owner and recovery evidence |
| Is ongoing monitoring ready for the transition? | Separate operational acceptance and cutover decision |
| Can the old account now be closed? | Named approval and agreed closure date |
The checklist is a planning aid, not a universal retention schedule. Record requirements vary by use, and a successful test on one file does not establish the condition of every record. Use the scope and risk of your project to determine the necessary review.
What should you do before the next renewal date?
Ask for a sample export now. Test a real retrieval question, document the limitations and put the remaining work on the transition schedule. That small exercise can uncover decisions that are much harder to resolve once access has ended.
Qualified Controls can help you define monitoring requirements and discuss a transition with clear responsibilities for systems, records and operational handover. Contact our team about your monitoring project with your current system, equipment scope and record-access needs. Start the conversation before the cancellation date becomes the project deadline.