When reviewing Microsoft's 'High Availability Solutions' (http://msdn.microsoft.com/en-us/library/ms190202.aspx) there's an interesting note toward the bottom:
'If you are running an edition of SQL Server that does not support AlwaysOn Availability Groups, we recommend log shipping.'
Note this is even with 'SQL Server 2014' chosen as the version at the top (versus choosing an older version to get its technical document). This should help give you a high level of confidence that Log Shipping is a very viable solution for your situation and isn't going anywhere.
No need to stop doing differentials either. Here's a great article on using differentials to help you refresh the Secondary: http://www.brentozar.com/archive/2014/09/log-shipping-magic-using-differential-backup-delayed-secondary/?utm_content=buffer69cb0&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer
When looking at Log Shipping, having a prepared solution for failing over (and possibly back) will be critical when having such a high number of databases. We use a SQL script I developed that helps generate the steps/scripts you need for such a Failover/Failback. If you want to get a running start on building a solution, consider starting with it and taking things from there (http://streamlinelogshippingfailovers.codeplex.com)
With Log Shipping in general, periodically perform the steps needed to help keep the Secondary a viable Failover option: Copy logins, scheduled jobs (disabled on Secondary), SSIS packages, etc.
It's also best practice to perform a DR test on a regular basis, which could also include copying the items mentioned above. For example, fail over to the Secondary, recreate logins based on scripting them out from the Primary, copy jobs (disabled), point your application at the Secondary to ensure it works and then fail back. This will help you know (and demonstrate) that you are truly prepared for a disaster.