Does this plan work as a Failover strategy-SQL Server 2016 Standard Edition
Do you think this plan will work?


Without a lot of headaches, no I don't. Most times I have witnessed an attempt to use replication for DR it has failed. Every time I've witnessed an attempt to 'fail-back' from a replication 'failover' it has failed miserably.

As you've mentioned, replication is not a HA/DR technology and shouldn't be used as such. If you're looking for a simple solution you can implement quickly, and you're going to log ship back to the primary for fail-back already, why not log ship to the secondary now and use an actual DR technology?

This gives you the option of performing tail log backups on the primary to leave it in a RESTORING state and makes fail-back much simpler. Your whole process is this - 


Tail-log backup the primary and disable log shipping jobs on primary
Run the LSCopy and LSRestore jobs on secondary then apply tail-log backup to the secondary. Disable log shipping jobs.
Bring secondary Dbs online. Ensure a log backup job is running against the DBs on the secondary.
Point apps at secondary
Patch the primary
Tail-log backup the secondary
Apply logs and tail-log from secondary to primary
Bring primary online
Point apps at primary
Re-enable all log shipping jobs.


Lastly, if you're on SQL Server 2016 Standard Edition - implement Basic Availability Groups. They're available in Standard Edition, you're paying for an additional server anyway with Replication or Log Shipping, and the whole process is much, much simpler.

Since you have an outage for the apps to re-direct them to the secondary, why not take the opportunity to point them at an AG listener and eliminate this whole problem going forward?