I can NOT recommend that.
I've done this work before and its painstaking and risky (but with lots of time and care possible). You end up with some pretty sophisticated SQL scripts that have to encapsulate the GP business logic that you are aware of (and the fear is that logic which you are unaware of and ultimately breaks the application). This would leave you vulnerable from a formal GP technical support perspective too (should have used the GP interface).
There are many dependencies between records, so simply deleting based on date does not work in many cases, as those old records may be required for something else to work properly. Indeed all may look fine until you next run check links or reconcile where GP then proceeds to delete what you regard as valid data -due to orphan dependencies.
The tables themselves have SQL triggers on them that fire as you delete data, so other tables can have data deleted from them when you delete a record elsewhere. So copying tables must be considered carefully as triggers may be pointing at the wrong copy of the data.
I could go on...
Its a minefield, even if you have years of experience in GP schema and application.
Your own tables are easier, assuming you understand your own dependencies. In that case yes your plan could work.
Sorry but there are no easy ways forward.
Also I agree with what @RichardWheeler said.
Tim
