1) I need to regularly insert/update the data in the new database on SQL server 2014 from the old (SQL server 2000) until we fully transition to the new server (SQL server 2014). Can somebody please share their experience/inputs? Will be really helpful to start with.
There is nothing good about this. You're putting load on your old server, to duplicate data to the new server, and it will take ages for you to build all of the ETL processes in (not to mention the risks you have in doing so), but what would be the benefit? It doesn't confirm your applications are still able to operate on SQL 2014. You really need to either have a dedicated and separate test environment, possibly with occasional database refreshes, and/or replay queries.
I'd go back to the drawing board. The normal process is:
1) Business wants to upgrade.
2) You copy your production databases into another environment (e.g. Test), cleanse data off where possible (e.g. PII data, email addresses). Automate this as much as you can because you will likely need to refresh often.
3) Testing would occur there to determine most of the functionality you require is available and still working. Most of this will be user testing, with developers checking application logs hoping that they aren't swallowed. On the SQL side you can capture traces and look for errors.
4) Then you would repeat the process with your real production environment.
You can move databases-at-a-time over, but replicating row-level information is not something that is normally done in this way for these purposes.
2) The next step is to encrypt the data (few columns) on the new sql server 2014 as and when data gets inserted. However, my priority remains the first step to get the insert working on the new SQL server.
The way you've described it this would have to be an application side change (technically you may be able to alter the stored procedures to encrypt and decrypt the underlying data, but what's seamless to the application is also seamless to anyone else querying the data). The best you can do without application support in SQL 2014 is encrypt data at rest (e.g. so if someone steals your disks or backup drives then you're secure). But then key management must be taken and tested extremely seriously.
Otherwise, you can do something similar in SQL 2016 or Azure Database with AlwaysEncrypted. That would require more minor application-side changes (at least I think the .NET library in use, they haven't released full details).
--
I'm tired. I take no responsibility for mistakes in an informal conversation.