Has anyone attempted to compress ledger entries in the Data Administration page in BC? Was there a significant savings in capacity after? Any suggestions on how to estimate the potential savings based on current size and rows in a specific table?
I’m asking our partner to alter the minimum age for compressing entries from 5 years to 3 years so we can go ahead and benefit from this (hopefully) space saving tool but it’s going to require an estimate of 15 hours of dev work.
It would be a lot faster just to try this out in test database /sandbox environment.
15h feels a lot, but if you really want to see almost exact numbers what will be the size difference of database, then of course it takes time - as someone has to do the calculations, maybe run the process on some copy system - and the waiting time for this process execution is added in this time (and it could be like 70% time just waiting) for what you have to pay 
If you have test system, you can run the process in a minute and then just wait - it could be couple of hours - and during this time other users wont be able to do any postings.
To understand what would be the savings - would need to know what are your preffered parameters and division by dimensions. The more dimensions you require to keep in entries, the less compression there will be.
There will be one entry created for staet of the compression period and one for each period (weekly/monthly/yearly). For example for customer there will be like opening balance just showing debit or credit amount and one line for each period , either debit or credit , so you will not see how many payments/invoices were posted.
The quote was actually just for the dev work. I have no idea what type of changes need to be made to the code. It feels like a lot to me too. Do you have experience with running this process in BC? We are only 4 years into the platform so I don’t have entries to test it with. I guess I could post some bogus transactions to 2019 to try it out.