The Team: who stands behind this guide and how it recommends

The Scope Record is an independent guide to HP-UX and OpenVMS on Itanium. This page sets out what we read, what we compare and what we will not claim.

Why this page shows a method rather than a biography

A reader deciding whether to keep, host or move an HP-UX or OpenVMS system on Itanium has a right to ask who is telling them so. We do not list years in the trade, certifications, memberships or awards here, because this site has none of them on record to show. What a reader can check is the method.

The method has three parts. We read the published material on each platform, we set what the sources say against one another, and we record what they do not settle. The material we read falls into three groups:

The platform's own release notes, support matrices and migration guidance, where the vendor still publishes them.
Trade press that reports support and lifecycle decisions, read for the dates it gives and the source it cites.
Engineering write-ups on porting, emulation and cluster behaviour, read as opinion until a vendor source agrees with them.

The questions that come out of this method run on our offering page, where a reader answers them about their own system.

Dates are checked against the document that sets them

Most of the decisions on these pages turn on a date: when standard support ended, when the last hardware order closed, when a release stopped being built. We take each date from the document that sets it and name that document beside it.

Teal fibre patch cables with LC connectors plugged into the ports of a network switch — Cabling and switch ports are where a move is checked by hand. A plan should name each connection it depends on before any date is fixed.

Where a source and a vendor notice disagree, the notice governs, and the disagreement stays printed on the page.

A senior systems architect studying a printed diagram at a wooden desk beside a small rack server — Illustrative, generated for this guide. It depicts no real firm, person or system.

The explainers carry the mechanics behind these dates, and the glossary defines the terms a vendor may use on you.

Three numbers that describe how this guide was built

8: pages in this guide, from the homepage to the privacy statement
17: sourced facts recorded in the research file behind the pages, each one with the source it came from
11: distinct published sources behind those facts, from trade press to vendor documentation

These count our own research material. They are not a measure of how many readers we reach or how many decisions we have looked at, and we claim neither.

The questions a reader asks before trusting a recommendation

Does this guide put a price on a migration, a hosting plan or a licence?

No. We looked for an authoritative published figure for migration cost, hosting cost and commercial OpenVMS licensing, and found only vendor marketing pages. A price a reader is offered should be checked against the vendor's own written terms.

How is a stay, host or migrate recommendation reached?

The recommendation follows five questions in order, the same five the decision helper on Our Offering asks: which system and CPU it runs on today, whether the source code and a working build still exist, whether someone can run and change the system without outside help, how much downtime the business can accept, and what is pushing the question now. Each answer narrows the outcome, and where an answer can push the result either way, the question says so.

What happens when a source turns out to be wrong?

A source can be out of date, or it can report a plan as if it had already happened. When two sources disagree, we print the disagreement and name the source we give more weight to, with the reason. Where a vendor roadmap is published only as an image that we could not read, we leave that date out rather than estimate it.

Where the method runs out, and what a reader should do then

Some dates rest on a single secondary report, or on a reference work that cites a notice we could not open. We mark those as secondary where they appear, and a reader should confirm them with the vendor before acting.

A reader who meets a gap should take it to the question it blocks. If the blocking question is which operating system and release is running, answer it first, because the rest of the decision depends on it. If it is the price of a migration or a licence, take it to the vendor, who can put the terms in writing.

To work through your own system, start with the decision questions, then use the ask page if something is still unclear.