How should I handle a critical production update without vendor support?

Do not start without a verified, restorable backup and a practical rollback plan. For a virtual system, that might include a tested clone or snapshot; for bare metal, use a known-good backup and confirm how you would restore it. Include enough time in the maintenance window to roll back if validation fails.

Treat it like any other production change: test the update on a development environment, clone, or virtual machine first. Make sure the test system is representative enough to reveal compatibility issues, and follow the vendor’s documentation closely. If testing goes well, schedule a maintenance window and perform the production change then.

Document the risks and your concerns in writing, including the fact that there’s no active vendor support. Ask management to explicitly approve proceeding through the normal change-control process. That creates a clear record that the decision was understood and authorized rather than leaving you to carry the risk alone.

Lack of vendor support does not automatically mean the update can’t be done—administrators often maintain systems themselves. The important question is whether this is a routine, documented update or something requiring specialized vendor knowledge. If management refuses testing, backups, change approval, or rollback time, put that refusal and the potential impact in writing before deciding whether the change is safe to perform.