Query tables with 400 million records fast Table: Customer Data
Rows: 400 million
Indexes: Non-clustered (as per queries)

Issue: Index Scan happening with most queries, 400 million scan take too long to complete
Need advise on how to address above problem:

Will partitioning the table by YEAR help improve performance or partitioning only helps in data management?
How to convert Index Scan to Seek (majority of reports using different columns, filters and aggregation)
Or simple approach: Keep current year in one table and rest all archived in historical table would be best
Any other feature in SQL Server 2019 which can be used when queries with such big data can return records faster.
Will partitioning the table by YEAR help improve performance or partitioning only helps in data management?

Yes. If your queries have date filters, Partition Elimination will allow queries to ignore some partitions.

How to convert Index Scan to Seek (majority of reports using different columns, filters and aggregation)

You don't really want that.  With a clever combination of indexes, filtered indexes, indexes with included columns, and indexed views it's possible to provide optimized query plans for many different query types.  But it's expensive, time-consuming, and and typically fails to account for 100% of the queries.  It's better to be able to support scanning, which brings us to:

Any other feature in SQL Server 2019 which can be used when queries with such big data can return records faster.

Yes.  Absolutely.  For large tables with a variety of queries that scan and aggregate large numbers of rows, you should use a Columnstore design instead of the default row-oriented Clustered Index or Heap.
To switch to columnar storage, just create a Clustered Columnstore index on the table.  It's designed for exactly this scenario, providing:

The fastest scanning speed.
The highest compression.
Queries can scan only the columns they need.
Data is stored and fetched from disk in larger chunks.
Unused columns are not fetched from disk or cached in RAM.
Can be combined with non-clustered indexes and partitioning if needed.

And once you can scan fast enough, you don't really need a lot of other indexes.