How to fine tune a huge problematic Heap Table? Problem:
A huge table is causing to a critical performance issue on a very critically important production database (MS SQL Server 2016 SP1 Standard Edition).
Facts about the problematic Table :

Heap Table without index.
450 GB of Size.
More than 190 million records.
More than 900 MB/s Physical I/O activity every time a simple SELECT
Query executes upon. Worst if the query includes WHERE clause.
Queries executed upon this table are causing 4-5 minutes delays on the application UI.

Suggested solution by the application/system manufacturer:

Convert the Heap Table to a Clustered Index Table.

Suggested performance tuning steps with respect to suggested solution:

Truncate db table (agreed with customer to delete records older than 1 year).

Don't Delete Records. Copy records created in last 1 year to a temp table. Truncate the original table, and then INSERT the records you have copied from the temp table to the emptied original table.


Make a de-fragmentation on the db table.
Migrate the db table from heap to clustered table.
Create a Clustered Index.
Create a maintenance job and schedule it to re-build the clustered index periodically.

My question to community:
How would you improve the performance of such a problematic table? What would you add to or remove from the suggested performance tuning steps?
Much appreciated and thanks a lot in advance.
Edited from here on:
OK, I didn't want to reply to all comments 1 by 1. So I'm editing the question and adding some more information.
1st : I am not an expert DBA. I would say an advanced beginner. That's why I am here to learn from the community as much as I can.
2nd : We just got this customer 2 weeks ago, and I have not got full access to the environment myself. This information (facts) about the problem, about the table is directly from the customer's sys admins.
3rd : There for, I have no idea why the table is Heap in the first hand, without an index, and they let it to grow this much without any partitioning and what so ever.
4th : Suggested Solution and Suggested Steps are not my own but directly from the manufacturer of the whole system (it's a well know Unified Communications System and the manufacturer is the best in this area. I guess you all know which one).
5th : I will hopefully have a full access to the environment next week and before that I just wanted to share what I got in hand and try to get as much opinion/suggestion as I could prior to going into this mess.
6th : Because unfortunately I am the one who is going to take this mess from here and try to make it better and smoother working mess.
Thanks to everyone who already spare some time and replied. I already got some insight. And I will definitely share more info as soon as I have more in hand.
Based on those facts, 190M rows, 450GB, un-indexed heap, long-running queries, you should create a Clustered Columnstore index and store the data in compressed columnar format.
However, that might not be the optimal solution, as you still have a table with no key and no indexes, which is strange.