I know that your question was specifically about partitioning, and Dan Guzman's answer is good, but have you considered alternatives?
You could make the clustered index be on the time series, perhaps even a composite clustered index of time series + primary key. This would keep the frequently fragmented parts (you said it was the most recent that changed) at the end of the b-tree and not require lifting large sections of the table over and over for index maintenance. Especially if the queries you use typically specify the time series component as part of the query then this would probably greatly benefit those queries.
I mention this because while partitioning will solve this problem, by letting smaller partitions be defragmented, Dan's answer passes over the maintenance aspects of adjusting partitions so that you have these rolling ranges of active vs inactive.
Here is a sample of how to setup a table for this. Of course, changing a clustered index on an existing table could take time, but I think it will be worth it.
/** DEMO TABLE
Note that I still have an Identity column going
Note that there is a default for the TransactionDate (what I'm using for the timeseries)
CREATE TABLE dbo.Demo
DemoPrimaryKeyID INT NOT NULL IDENTITY(1,1)
, TransactionDate DATETIME2(7) NOT NULL CONSTRAINT DF_Demo_TransactionDate DEFAULT (SYSUTCDATETIME())
, TransactionValue DECIMAL(10,2) NULL
/** I've created a composite clustered index here.
The table will be stored in TransactionDate, then DemoPrimaryKey order
CREATE CLUSTERED INDEX PK_Demo
WITH (FILLFACTOR=90, SORT_IN_TEMPDB=ON)
/** IMPORTANT - I have a unique index/constraint on the DemoPrimaryKeyID
CREATE UNIQUE NONCLUSTERED INDEX IDXUQ_Demo_DemoPrimaryKeyID
WITH (FILLFACTOR=100, SORT_IN_TEMPDB=ON)