Exactly but much, much more. I'm suggesting that a "crawler" be built to partition the table one month at a time, do a final true up when it's done, and then swap-rename the tables. Then you could split the index maintenance to only those partitions that needed it. For a really BIG bang for the buck, each monthly partition should live on a separate filegroup with each filegroup containing only one file. Then, you only have to backup the filegroups that actually suffered an update. Usually, that's limited to only the last 1 or 2 partitions and all the rest can be set to read only, backed up once, and never need a back on those partitions ever again. I'm in the process of doing this on a 310GB call recording table that currently takes 6 hours to backup. Once I'm done with it, I'll only need to backup the latest partition and, just before the end of the month when it is most full, that should only take about 6 minutes. I'll also be able to move the Read Only stuff from expensive and cherished SAN hardware to lower cost iSCSI disks in the process.

I do have to tell you that if you partition the table and you thought it was all too easy to do, then you've probably done it wrong and have condemned large parts of your disk to a Read Only status.