I found these bugs first in Able Gold and later confirmed in v9.

Steps to reproduce:

Create a user
Place 1 order for the user, shopper side or admin it doesn't matter
Now delete the user you just created

Bug #1:
Pull up the order in order manager. Customer profile tab still renders. This shouldn't render since the user associated to the order no longer exists. Clicking it throws an exception.

Bug #2:
Click the move order button at the bottom. Console shows a 500 error. Move order UI never renders.

Bug #3:
Even if you could pull up the Move-order dialog, the orderRepo.UpdateUser() routine will fail to move the order to the selected user. The reason is the routine is written assuming the oldUserId on the existing order will be 0. But SQL cascade-update set the UserId to null on the order object when the user was deleted, not 0. So all of those ugly manual SQL queries that have a 'WHERE UserId = :oldUserId' will fail to find the order involved. They have to all be modified to 'WHERE UserId IS NULL'. In fact, specifying the old user id isn't even necessary when updating the order object. It can only ever have 1 user associated to it anyways so there's no point in making it part of the where clause.

However this poses a problem once you get to updating user groups and subscriptions as the overall SQL schema is not consistently designed. Some tables get a cascade-update that set UserId to null, others like user groups appears to simply cascade-delete the entire child data object.

This feature needs some serious love to be stable. And those hard-coded SQL update queries deviate from accepted nHibernate implementation practice. Somebody got lazy.