Migration
Your ERP has an end date. Now what?
Steelhead has acquired Visual Shop and Bluestreak and published the date each will be retired. If you run either, the decision you did not plan to make has a deadline attached to it.
The dates
What has actually been announced
These are Steelhead's own published commitments, not our characterisation of them:
- Visual Shopsupported until the end of 2027, then retired
- Bluestreaksupported through 30 June 2028, then retired
Both announcements use the same wording: "All AI and product development will be focused on the Steelhead platform." Existing customers are offered a migration onto Steelhead, with incentives for moving early.
None of that is hidden and none of it is unusual. But it means the timing of a system change this size now belongs to somebody else's roadmap, and a migration you are given a date for behaves differently from one you choose.We wrote about that in more detail →
What moves
The thing at risk is your evidence, not your screens
Losing a user interface is an inconvenience. Losing the ability to answer an auditor is not.
Your current system holds SAT and TUS records going back years, instrument calibration history, thermocouple lots and their expiry, load records with the cycle each one ran, test results, and the certificates you issued against all of it. Under AMS 2750 and an AC7102/8 audit, that history is your compliance position. It is evidence, not reporting.
So the question is not which system has the nicer screens. It is which one can still answer, in 2031, what was true about a furnace on a day in 2024.
Your data
We will migrate whatever you want to bring
Master data, order history, pyrometry records, load history, issued certificates — if you want it in the new system, we will move it. That is part of the engagement, not a paid extra and not a module you have to buy.
What we will not do is run it through a one-click importer, and it is worth saying why, because the reason is the same one this whole page is about.
Your current system's model of a system accuracy test is not identical to ours. Neither is its idea of a load, or of which cycle a charge actually ran. A generic import maps one onto the other and gets some records subtlywrong — not obviously broken, just quietly inaccurate. You would not find out which ones until an auditor asked about a load from the year you migrated, which is the worst possible moment to discover it.
So it is done deliberately, with you:
- You decide what comes across. Some shops want everything. Some want master data plus two years of pyrometry and certificates, and keep the old export as the archive for anything older. Both are defensible.
- We map it explicitly — field by field, with the awkward cases named rather than guessed at.
- You verify a sample before cutover. Pick jobs you know well, including a load whose pyrometry you can check by hand, and confirm the migrated record says what the original said.
- Then you cut over, and everything after that date carries its evidence natively.
One thing to do regardless of who you choose: get a complete export out of your current system early, while it is still supported and the vendor still has a reason to help. Keep it. The retention obligation on those records outlives the software by years, and an export you already hold is leverage you cannot lose.
What to demand
Five questions for any replacement, including us
You have leverage now that you will not have in eighteen months. Spend it on these:
- Can I export everything, myself, without asking? Not a report — every record, in a documented format, on demand. If leaving requires a support ticket, you are choosing a landlord.
- Is pyrometry modelled as dated records with intervals, or as fields on a furnace? This decides whether you can still answer "was this furnace in compliance on the day this load ran" in three years.
- What is the as-of-date behaviour? If a calibration is recorded next year, does last year's load still show the calibration that applied then — or has it silently updated?
- Do issued certificates stay immutable? They were signed. They should not become editable rows in a new schema.
- What does year three cost, after the switching incentive expires and moving again means doing all of this twice?
Question three is the one people skip. A system that overwrites history rather than preserving it will pass every demo and fail the one audit that matters.More on evaluating software against the standard →
Where we stand
How HeatLock answers its own five questions
We built a competing product, so weigh this accordingly — and hold us to the same list.
Export: everything the system holds, on demand, yours.Pyrometry: SAT, TUS and calibration are dated records with their own intervals, and validity is computed from them rather than stored as a status. As-of-date: the evidence in force is frozen onto every charge at build time, so a later record cannot rewrite what was true then.Certificates: immutable once issued — wrong means void and re-issue, which is what an auditor expects to see.
And the thing none of the above describes:an out-of-compliance furnace is refused a load, before the charge exists, with the reason named.
Bring the furnace you know is overdue
The most useful demo starts with your own equipment list and a furnace that is late on something. Thirty minutes, and we will trace one of your jobs end to end.