The extended support for Dot Net Framework 1.1 is ending in the September 2013,it enforces everyone to do the framework upgrade to higher version to get the benefit of microsoft support. After doing research decission is taken to upgrade to 3.5 SP1 which obviously get extended support until 2020.
After successful migration using Visual Studio 2008, The obsolete methods are shown as warnings and the application runs successful without doing any changes to obsolete methods.
If in case if those warnings are not changed as per the recommendation.Will microsoft support them in case of any issues as per 3.5 SP1 Support end date.
Could you please suggest correct action.
Define "support"?
When a member is marked as Obsolete, it's still there, unchanged, with the same behavior, it just means that it may be removed at some point in the future - legacy applications that still use it will continue to run, but new applications should not use that member or feature.
If you're referring to "customer support" - as in if you give Microsoft a phone call and cough up for the Developer Support fee, then yes, the man-at-the-other-end-of-the-telephone will help you and maybe provide a hotfix if you discover a bug or problem with the marked-as-obsolete feature. After the extended support period ends, then Microsoft will not provide personal-level support for that feature, or anything in the entire product (the assumption being that you'd have upgraded to 4.0 or 5.0 or whatever) by then. But if your program works fine, and Microsoft pledges runtime support in future versions of Windows (as it has for VB6 on Windows 8) then this is a non-issue. Also, Microsoft does not remove impersonal, online support (e.g. KB articles) so you can still rely on that. But 2020 is 7 years away, we'll be up to .NET 6.0 by then.
But if you do upgrade to say, .NET 5.0 and see that the Obsolete'd feature has been removed, that you need to change your code accordingly. Also Obsolete'd items (generally) will not be removed in point-releases or service-packs (unless it was a majority security issue).
Remember, writing desktop software is not the same thing as mainframe software - the platform will change, your applications will break, and you have to keep on running the treadmill. The best you can do is conform to the platform requirements and pray for forward-compatibility. (This is the reason so many Windows 9x games don't run on modern OSes: the developers couldn't spare the time to do things properly, which sucks).