Just wondering if this is too much of a jump upgrading from Barrier Breaker 14.07 to latest 21.02?
I have a WD My Net N750 which appears to be compatible: https://firmware-selector.openwrt.org/?version=21.02.1&target=ath79%2Fgeneric&id=wd_mynet-n750
Thanks,
Perry
You will absolutely need to reset the settings to defaults (and do not attempt to restore a backup from BB to 21.02 -- it will not work).
The upgrade involves also involves a significant change to the target architecture (from ar71xx to ath79 -- it is a change to the way everything under the hood works while still targeting the same hardware).
I'm pretty sure that you cannot do this in a single upgrade, but I'm not 100% certain if you'll be able to do this in two steps or if it will require more. I'd recommend upgrading to 19.07/ar71xx first, then running the upgrade to 21.02 after that.
For the most likely success, you should probably reset your router to defaults before running the upgrades. Then, use the sysupgrade images to go from BB > 19.07 > 21.02. If you use the LuCI web interface, you will be presented with the option to keep settings -- do not keep settings for either one of these steps. If you use the CLI, be sure to include the -n switch (which specifies to not keep settings).
When you upgrade from 19.07 > 21.02, you will be changing the target architecture and you will get a scary looking warning. It is okay to proceed (again, do not keep settings).
It is best practice to make sure that the checksum matches what is published on the firmware selector page -- this way you can be sure that the file has not become corrupt along the way (this is rare, but can happen).
Because sysupgrade mechanism (image metadata) changed somewhat in 2016, I would first sysupgrade to 17.01 , in order to get the new logic for the later sysupgrades, and then probably to 19.07, still with ar71xx architecture.
All sysupgrades without keeping settings...
(So jumping over 15.05 and 18.06)
Then sysupgrading to ath79 architecture 21.02. that needs "force" option as ar71xx/ath79 causes image verification to fail.
The other alternative would be to read the advice from the device wiki page, and take the bootloader recovery flash route directly to the 21.02.1 factory image (and then for some strange reason also reflash with a sysupgrade image).
fyi, I think 21.02.1 may be broken for MyNet N750.
I have a MyNet N750 running OpenWrt 19.07.7 ar71xx. It had been upgraded over the years from 18.06, 17.01, keeping settings each time.
I just flashed 21.02 squashfs-sysupgrade using LuCI without keeping any settings. I was able to log into LuCI, but when I selected 'Reboot' in LuCI, the router restarts but LuCI fails to load.
I can SSH into the router. I tried forcibly unloading LuCI and reinstalling LuCI but it did not resolve the problem.
Next, I scp sysupgrade.bin and ran sysupgrade -n -F. Router rebooted and I was able to log into LuCI again. But as soon as I reboot, LuCI fails to appear when router starts up.
Next, scp sysupgrade.bin and ran sysupgrade -n -F. Router rebooted and I was able to log into LuCI again. I then installed sysupgrade.bin file again using LuCI. But as soon as I reboot, LuCI fails to appear when router starts up.
Next, I used Emergency Room recovery method and installed the 21.02.1 squashfs**-factory**.bin. Router rebooted and I was able to log into LuCI again. I then installed sysupgrade.bin file using LuCI. But as soon as I reboot, LuCI fails to appear when router starts up.....
Looks LuCI is broken in 21.02.1 for MyNet N750 to me?
Update: My tests seem to indicate 21.02.0-rc2 is last release where LuCI can survive a reboot.
Thanks to all of you for some very concise and detailed information. I'll have to digest it all and determine my best plan of attack 
One additional question that I should have included in the original post...
What are the overall benefits of doing the 14.07 > 21.02 upgrade? My initial reason for investigating this was for stability issues I've been having. And hoped this upgrade would help alleviate some of the WIFI outages I occasionally have. Not terrible, but I do have to manually reboot about once a week. This is in addition to the automated reboot that I have running every night.
Thanks
Security upgrades, much better IPv6 support, wifi driver developments, QoS tools (SQM with modern qdiscs)
(You get most of those with 19.07 already)
If the only problem is LuCI not loading properly, try clearing your browser cache. There may be incompatible old LuCI pages in the cache on the PC.
This part is huge...
14.07 is extremely old, unsupported, and has many known and actively exploited security vulnerabilities.
Upgrading to 19.07 or 21.02 gets you back into supported territory (although technically 19.07 will go EOL in the relatively near future), with up to date security patches, new features, and up-to-date offerings with the package manager (should you choose to use them)
If your issue is related to the stability of the firmware itself, 19.07 and 21.02 seem to be pretty solid for most devices. However, I don't know how many people are using your specific device, and per the comment from @bill888, there could potentially be some issues with that unit (but @mk24 points out that it could be browser based -- we'd need additional datapoints or experiments to know for sure if @bill888 's experience actually indicates any real issues)
If your situation is caused by failing hardware, though, you will be best served by replacing the unit.
Sounds like maybe going from 14.07 > 17.01 > 19.07 to start would be my best bet. And probably the lowest risk. I can see if that's enough for now at least. Then I can decide later if I need/want to jump to 21.02.
Sadly clearing browser cache in Chrome web browser for Windows does not resolve the problem. I've been opening new incognito windows throughout my testing.
I don't think I've come across any postings where LuCI stopped working after first reboot, starting 21.02.0-rc3 for other devices.
Update: If I sysupgrade from clean install of rc2 to rc3 and 'keep settings', LuCI in rc3 survives reboots. Will investigate tomorrow.
When you jump to 19.07, decide if you wish to stay with ar71xx images, or make big leap to using ath79 images (you can't keep settings when upgrading from older release such as LEDE 17).
As reported last night.
If I sysupgrade from 21.02.0-rc2 to a later release such as 21.02.1 and 'keep settings', I have observed LuCI survives subsequent reboots (until I reset the device to default OpenWrt settings)
I also observed when I back up the settings while LuCI survives reboots, and then restore the settings, I get 'LuCI Configuration interface' followed by "Bad gateway". WinSCP then refuses to connect until I reset the router to restore openwrt defaults.
I couldn't find any differences between the files in /etc/config. Only the ULA prefix in /etc/config/network differed.
21.02 seems to be snafu on MyNet N750....
I've put 19.07.8 ath79 image on the N750 and it doesn't exhibit the LuCI or backup/restore issues so far. I know 19.07.7 ar71xx image works reliably.
ath79 vs. ar71xx should not cause any material difference.
It is only about how the hardware is described to the OS.
(old style mach-xxxxxx.c in ar71xx vs. modern DTS in ath79)
Might be about the host ssh certs and the SSL cert for LuCI (for uhttpd daemon). Browsers (and SSL enabled tools in general) are sometimes really picky about connecting to the same host if the certs have changed during a browser session.
WinSCP (and PuTTY) gives a specific warning if it's cert-related.
Clearing browser or restarting incognito session with chrome wouldn't work after I performed a simple restore of settings. I didn't investigate the WinSCP issue.
Only way I could regain access was to reset OpenWrt to default settings on the N750.
Ideally require another MyNet N750 owner to verify whether there are indeed problems with the 21.02 images. I've not encountered any of these weird issues with other openwrt devices when using 21.02.
I had a weird problem on a device and noticed this forum link here when considering 21.02.2.
I had the followg installed on 19:
luci-app-wireguardsnmpdtcpdumpAfter upgrading to 21.02.1, I started having network issues when saving settings (e.g I would loose wireless, log errors on the partition, etc.). One error read off a blurb of a config file. 
Currently I have omitted those programs as a workaround.
I have another running default software now too - I don't see issues (I upgraded it to 21.02.2 already).
This device failed.
reboot the would not boot back upI had to use the Emergency Room firmware recovery to downgrade to 19.07.9.
(Also, I don't recall doing this when I first switch to OpenWrt; but I had to use the Factory in Emergency Room, then flash again with sysupgrade after it booted. Otherwise it rebooted into the same unusable state - just FYI.)
[ 11.310024] jffs2: error: (600) verify_xattr_ref: node CRC failed at 0x9b0128, read=0xfffaff7e, calc=0xced28f4a
[ 11.320345] jffs2: error: (600) verify_xattr_ref: node CRC failed at 0x9b0050, read=0xfffff7fb, calc=0xb925e3b5
[ 11.331096] jffs2: notice: (600) jffs2_build_xattr_subsystem: complete building xattr subsystem, 34 of xdatum (20 unchecked, 11 orphan) and 41 of xref (10 dead, 0 orphan) found.
[ 11.347925] jffs2: notice: (600) jffs2_get_inode_nodes: Node header CRC failed at 0x9b000c. {fdff,e77a,fd7ae77e,fdffe77e}
[ 11.360880] jffs2: notice: (600) jffs2_get_inode_nodes: Node header CRC failed at 0x9b026c. {fdff,e77a,fd7ae77e,fdffe77e}
[ 11.374001] mount_root: switching to jffs2 overlay
[ 11.381682] jffs2: error: (601) do_verify_xattr_datum: node CRC failed at 0x9b00dc, read=0xfdfef7ff, calc=0x21946102
[ 11.393535] overlayfs: upper fs does not support tmpfile.
[ 11.407995] urandom-seed: Seeding with /etc/urandom.seed
[ 11.514146] eth0: link down
[ 11.531531] jffs2: notice: (1) jffs2_get_inode_nodes: Node header CRC failed at 0x9b268c. {7600,ffff,00000044,a4ef223e}
From another device running 21.02.1. Can't recall if this was some of the relevant logs I saw before...(as it's still running, LOL).