Not entirely dogmatic but I've always found https://github.com/jnguyen095/clean-code/blob/master/Clean.Code.A.Handb… to be a good guide.

this has sections on veriticle and horizontal formatting/density/distance.  Again, not a specific answer but I use it as a guide.

I'm struggling to understand your original question "We are attempting to "Repoint" old class data to new class data to save disk space and data redundancy across multiple tables.  "

Will "Repoint"ing acutall save disk space?  At first glance it would be hard to see how that would make a significant difference.  It might be true that the old class has a number of properties that are no longer used so in the physical storage you have a number of unused storage element but I wouldnt think that would make a significant difference.  

One area that can make a difference is if your classes utilize bitmap indices and if you have rapidly changing data with fields are indexed.  IRIS delivers %SYS.Maint.Bitmap which is described as 

This utility is used to compact bitmap/bitslice indices. Over time in a volatile table (think lots of INSERTs and DELETEs) the storage for a bitmap index may become less efficient. To a lesser extent index value changes, i.e. UPDATES, can also degrade bitmap performance.

This utility can by run on a live system. It will loop over all bitmap/bitslice indices in a class or namespace and compact them by either removing a chunk that is all zeros or by using $BITLOGIC() to compact the bits.

Consider Ens.MessageHeader which has a bitmap index on Status where the Status values are 

1=Crerated

2=Queued

3=Delivered

4=Discarded

5=Suspended

6=Deferred

7=Aborted

8=Error

9=Completed

You can imagine that a Message Header is save with 

Event 1 Status=Created

Event 2  Status=Queued

Event 3  Status=Delivered

Event 4 Status = Completed

in the normal course of processing

This would have the side effect of 

1. Event 1 setting the Status =Created bit on

2. Event 2 Setting the Status=Created bit Off, Setting the Status=Queued On

3. Event 3 Setting the Status=Queued bit Off, Setting the Status=Delivered On

4. Event 4 Setting the Status=Delivered bit Off, Setting the Status=Completed On

all of this means that the bitmap index for 

Status=Created, Queued, Delivered over time is just a series of off bits and in many cases the entire bitchunk is just a bunch of off bits(although there is some compression here).

I have utilized  %SYS.Maint.Bitmap on systems that have existed for many years and saw some noticable space savings.  However, once run it doesnt seem to make a lot of sense to run very often.

https://github.com/synthetichealth/synthea can be used to create synthetic data, FHIR being one of the formats