In the video, the whole upgrade begins with one small click: opening the profile to read the build number. That number is the server's identity card — it decides which update file you need, which release notes apply to you, and what support will ask first when anything breaks. Make a habit of it.
Admins who upgrade Endpoint Central calmly for years share one unglamorous habit: they never touch an update file until they can say their current build number out loud. Everything else — the right PPM, the right release notes, a useful change log, a support case that gets answered quickly — hangs off that one number. This page turns the video's first step into a standing routine.
As the video shows, open your profile in the Endpoint Central console and the build information is right there — product, edition and the full build number. That screen is the official starting point of every upgrade.
Read the whole number, not just the family. '11.4' tells you the generation; the digits after it are the service-pack level, and they are the part the update file cares about.
The pattern is a short story: the leading numbers identify the product release line — 11.4 for the generation running through 2025 — and the trailing series marks the service-pack builds within it, with the 25xx range being the 2025 line.
That reading skill pays off when you skim release notes: you can instantly tell whether a readme entry belongs to your generation, your year, or a different track entirely, such as the cloud edition's own versioning.
Service packs upgrade from specific builds. The console's own update prompt is the safe source because it offers the file matched to the build you are running; a manually downloaded PPM deserves a manual check of its stated starting build against yours.
A mismatch is the most common self-inflicted upgrade failure — the installer refuses or fails, and the admin blames the product. Thirty seconds of comparing numbers prevents the entire genre of problem.
ManageEngine publishes a hotfix readme — release notes — for every build. Before applying one, skim its three movements: what is new, what is enhanced, what is fixed. Note anything touching modules you rely on daily.
Those five minutes calibrate everything else: they tell you the build's urgency, warn you about changes your team will notice, and give you the sentence you will later paste into the change log. It is the cheapest insurance in the whole upgrade process.
After each upgrade, write one line somewhere durable: the date, the from-build, the to-build, where the pre-upgrade backup lives, and who applied it.
Future you — mid-incident, six months from now — will be grateful. So will ManageEngine support, whose first question on any upgrade case is the question this whole page is about: what build are you on, and what build did you come from?
The first click in the video is the build number — see why everything else follows from it.
▶️ Watch Full VideoIn the console, open your profile — the build information shown there is the one your next PPM must start from, and it is where the video begins.
Use the console's own update prompt or ManageEngine's official pages. The console's suggestion is safest because it is matched to the build you are actually running.
Monthly is a sane rhythm for most offices: check the release notes, note anything security-related, and fold the rest into your next maintenance window.