There are 2 migration approaches
- Side by side: In which you get new VM, install new version of SQL Server, move databases by backup restore, move other logins and jobs.
- In-place Upgrade: You run the SQL Server 2016, then select upgrade to SQL Server 2016 and it will upgrade.
The approach you choose depends on downtime you get and complexity of database. Before you start you need to run DMA tool on SQL Server 2012 to find out all the breaking changes when moved to SQL Server 2016. You also have official document stating Breaking Changes in SQL Server 2016 when moving from lower version. The DMA will generate report and you can share it will all the stakeholders, get the approval, and then upgrade.
You also need to test your application to new version of database. Post migration update the stats of complete databases and change the compatibility level of databases to that corresponding to SQL Server 2016. You also have option to continue with old compatibility level.
Now for impact it depends on features and deprecated features you are using in SQL Server 2012. A main concern is "CE regression" which mostly comes when you upgrade to SQL Server 2014 and above due to new CE. This can easily be solved by using old compatibility level or using query hint and force database to use old CE. See example below
ALTER DATABASE SCOPED CONFIGURATION--forcing while DB to use old CE
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO
USE db_name
GO
SELECT PurchaseOrderID, OrderDate
FROM Purchasing.PurchaseOrders
WHERE OrderDate = '2016-05-30'
OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'));--forcing only this query to use old CE