How to reproduce "Could not continue scan with NOLOCK due to data movement"
Since one potential 'band aid' to the NOLOCK issues is to stop using NOLOCK and begin using READ_COMMITTED_SNAPSHOT isolation, I want to point you to the blog post at http://www.brentozar.com by Kendra Little: Implementing Snapshot or Read Committed Snapshot Isolation in SQL Server: A Guide. 

Kendra provides a fair amount of detail on benefits and risks with using the READ_COMMITTED_SNAPSHOT isolation level.


This isolation level becomes the default isolation level for the database code.
You have to have only one user in the database in order to make the change to the READ_COMMITTED_SNAPSHOT isolation level.
Even if you use READ_COMMITTED_SNAPSHOT isolation you will still need to remove the NOLOCK hints since they override the default.  
Some of your code may well have problems that need curing.


Some years ago we implemented READ_COMMITTED_SNAPSHOT isolation on a database that was severely suffering from blocking.  But once we changed the isolation level we began getting deadlocks in a couple of critical areas.

Why did this happen?  Because the previous isolation level caused heavy blocking, the code could "never" reach the point of deadlocking.  However, with 
READ_COMMITTED_SNAPSHOT isolation, the queries could keep moving forward. However, some percentage of the no-longer waiting transactions began deadlocking.

Fortunately our case was resolved quickly by determining the deadlock points and adjusting the indexes on a couple of tables to have a more rational column order.  This greatly reduced our locking problems.