Sql server partitioned table: what happens when an update of a record changes the destination partition?

I my company we are facing performance issues on a big Sql server DB (running on Azure, total size > 150GB).

We have one big table (1,5GB, 3 millions records) that has several quite slow "select".

Those records have an "insert date" and I know that it is easy to make partitions based on date.

But I am exploring a different idea.

I have a "Status" column that can have different values, one of them is "Closed" and different other values that I’ll call "Open".
My idea is to add a calculated persisted column with a value that can be "Open" or "Closed", i’ll call it OpenClosedStatus.

"Closed tickets" continue to be accumulate and are rarely (if ever) read again, instead "open" tickets are normally less than 100 so having a dedicated partition should allow extremely fast read of their values.
Please note: the record is inserted once, selected potentially several hundred times and finally updated once (the update sets the "closed" status).

It is very complex to make proper indexes to speed up the several selects on the "Open" tickets because we have hundreds of instances of different programs that read "open" tickets accordingly with different criteria, therefore I am considering to partition them accordingly with the OpenClosedStatus.

This idea implies that a ticket is always inserted in the "Open" partition, then it should be transferred to the "Closed" partition when the status is updated as closed. The "OpenClosedStatus" will always be used in the WHERE clause of our queries, at least when searching for "open" tickets (therefore going on the small partition).

I do not find a reference of this "dynamic change" of partition on update of the record, I am therefore looking for advice for or against this atypical usage or partitions.