AWS EC2 migration to Azure VM using nodsjs code

This is quite an open-ended question, and depends a great deal on how your application is currently set up, and what the goals of migrating to Azure are. With that said, here are some avenues for investigation that may help.

Infrastructure as a service

You mention "EC2 instance", so I'm assuming that it's a single VM, rather than a cluster. You can set up VMs in Azure and choose templates for the VMs e.g. here are preconfigured Node.js boxes that you could use as a starting point: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/category/compute?operatingSystem=acom-linux&search=node.js

Once set up, deploy to the VM like you would normally deploy your application; making sure to install any dependencies that your application needs. Ideally you'd be automating and scripting this, rather than working directly on the box :-)

Platform as a service

Azure also has an interesting PaaS offering in the form of Azure App Service, and running Linux on App Service is now in preview. (See https://docs.microsoft.com/en-us/azure/app-service/app-service-linux-readme)

There are two ways that you can use this:

1. If your application runs in a Docker container, then you can create a new app that pulls your container from a Docker registry (e.g. Docker Hub). Find out more here: https://docs.microsoft.com/en-us/azure/app-service-web/app-service-linux-using-custom-docker-image

2. You can also set up a new app on the Node.js stack, and git push your code to the provided endpoint. Azure will then build and run your application. Find out more here: https://docs.microsoft.com/en-us/azure/app-service-web/app-service-web-nodejs-get-started

Other considerations

If your application uses services that run on other VMs (e.g. a standalone database), consider moving it over to Azure in parts to simplify the work, and prove at each step that everything still works as expected. For example: move the application servers first. Then the database. Then any other services. This isn't advisable on production databases (you may hit up against any number of issues like running out of connections or creating unexpected locks); and you'll want to be careful of egress bandwidth costs both ways.