It is said that kanban methodology is suited for software maintenance
and support areas whereas scrum for new product development.

I think most people in the agile community would disagree. Both Kanban and Scrum are suited for new product development (I have worked on a greenfield project with Kanban).

It is true that they have different strenghts and weaknesses, and that Scrum in its original form is not suitable for software maintenance when quick responses are paramount, but then most teams do not use a “pure” methodology, but tailor it to their needs.

Which agile approach is best suited for a project which is basically a
re-platforming from one technology to another(say from java to .net).

The agile answer would be: Don’t. A complete rewrite is rarely a good idea, and most importantly goes against one of the fundamental ideas of agile development, namely to focus on delivering value quickly: If you do a complete rewrite, you’ll probably not deliver any value until you are done (and possibly never, if you fail). See for example: to rewrite or not to rewrite, and Joel on Software – Things You Should Never Do, Part I. It is usually better to fix the parts that cause the most pain, possibly migrating to a different technology bit-by-bit (e.g. module by module). It may look more difficult in the beginning, but will give you results much faster, and reduce risk.

That said, if you feel you must rewrite, the methodology does not depend on the fact that it is a rewrite. Rather, it should depend on how your team is composed, how they want to work, how you communicate with stakeholders, etc. Both Kanban and Scrum will be well suited.