What steps should I take before performing a release upgrade to avoid problems?

important production system

I would not upgrade a system like that. I would install 16.04 on another machine, copy the live data over to that machine. Test, test some more. And then make that machine the production server.

And you can redo this with 18.04 with the current 14.04 server.

Why take risks at all?

I would take an Image Backup ("dd" in a Linux Live System) of the Workstation and convert this to a VirtualBox VM. (RAW-Image to VDI). After that make a snap and run this Image in VB. Play all the step to upgrade. If something isn't working put the snap back. After having a upgraded system you can convert the VDI back to raw and "dd" it to your system or play the run-book.
But always make a last "dd" Image backup before you overwrite your old system.
I prefer to run my systems from a USB Thumb-drive so system-install is done with "VDI - >RAW -> usb tumb-drive" and boot from the upgraded/installed system. ready. Okay you "loose" one USB port but you never will have stress and you can alway do easy a system-backup. I do this with my workstation and servers in production for years now.

Here's a variation of @rinzwind's answer that might work with the hardware you already have.

If you have (or can free up) enough free space on your internal disk drive(s), you can create 2 new partitions (using something like gparted from a live CD/USB distro) and copy root (/) to one of them and /home to the other and label them something like root2 and home2 so they're easy to find.

If root and home are in the same partition, you can just copy that, but it's a whole lot nicer for many reasons if they're separate.

You'll have to point the new root at the new /home by editing the changes into /etc/fstab on the new root partition (updating the UUIDs of the new /home and root partitions).

You get them by doing an ls -l /dev/disk/by-label to find the devices the new root and home are currently on and then running ls -l /dev/disk/by-uuid to get from the device names to the uuids.

Next, update grub (from your production system) with something like grub-customizer to add the new root to your grub menu.

Now, you'll have an exact copy of your live system on those partitions. You can run the upgrade on this copy and still have the production version intact. You can boot into whichever one you want to work on.

Once you're done with the upgrade, you can just tell grub that the copy is the live one (default entry) and that the original is now the backup. grub-customizer makes doing things like this fairly easy.

If you have too much data in /home or root (making them too big to duplicate), put it in its own partition first (being sure to tell the programs that access it about the move). It doesn't need to be duplicated - just backed up.

This also makes backing up your data a lot easier because it's no longer mixed in with system stuff.

With a second set of "test" partitions, you can now try all sorts of things you wouldn't want to risk on the system you depend on for day to day work.

I'm currently running Kubuntu 12.04 like this with 16.04 in my "development" partitions until it's configured the way I want it.

With disk drive prices so low these days, you could even copy your existing internal drive to a new larger one and use that if necessary - if your company will let you.

This answer covers all the major details of how to do this. I didn't try to cover every small detail of each step. But since you're working with a copy of everything there shouldn't be any serious issues and everything else has already been covered somewhere here on stackexchange.