I was hired by my current employer, an online retail concern, going on 6 months ago to help the company migrate from ASP/Oracle 9 to ASP.NET/Oracle 10g -- they won't even consider Microsoft SQL Server; I already tried ;^) ... we have a full-time Oracle DBA, so the 10g will go pretty smoothly.  .Net development is my passion.

The hardware configs out like this:
Oracle on IBM/AIX machines
ASP on IIS 5.x, Windows 2000 Servers
ASP.NET on IIS 6.0 Windows 2003 Servers
Business objects reside in sProcs (or Oracle Pkgs), inlcude files, ASP code, Oracle Reports, and other files! (A real mess!, with NO documentation of any kind!!)

We are a "load balanced" retail farm operation, that wholy depends on our Internet services as our primary revenue generation mechanism; dozens of blades, running dozens of servers.  We have tens of millions of lines of code, originally migrated from COBOL/IBM (don't ask!) to ASP/Oracle.

I am familiar with ASP to ASP.NET migrations -- have 1 full; 1/2 partial (small- to mid scale migrations) under my belt -- and we have one additional .Net developer on staff; out of ten total developers.  On a daily basis, we get "orders from above" that require current ASP code mods, builds, new functionality, etc.  Typically, we'll get mock-ups from Marketing (and other dept's), and the Mgr's & VP will micro-manage development to the point of "we don't have time to populate a drop-down listbox, so don't do that part." Etc.! 

In PRACTICALLY EVERY weekly meeting since I came on board, I have brought up the issues required for a migration -- strategy concepts (vertical -vs- horizontal), data issues, technology issues (like Session management software or tools), training issues, etc. -- practically to no avail.  The VP & I.S. Mgr. subscribe to-, and verbally acknowledge the "we'll have a quick fix" attitude toward the project; neither have a clue about .Net, what it does, how it does it, nor what a migration consists of, regardless of the white papers I send them.  Every meeting we have, "us two" .Net developers have to explain to [them] why "we don't use include files; we use embedded controls."  They go ahead and assign (to other) developers the "just add an Include file to ___" when we (the two .Net developers) leave the room.  Later that day, we have to touch one of the pages that one of the ASP developers checked in (to VSS) and we're pulling our hair out, because their include file contains (among many other NO-NO's):  

Set MyLocalObj1 = Application("Obj1")

I did a CBA (cost/benefit analysis) for in-house .Net training, and presented it to my manager ~2 months ago.  Only feedback to date: "We have a training budget."  I can quote the VP as saying, "I don't care if I have to hire 100 .Net developers, we'll meet our migration schedule."  The project is slated for July'07 start to Sept'07, completion, again, no docs, mixed systems, mixed business rules/objects at all levels of the operation, and a "we don't have time for ___" mentality.

From a 10,000 foot point of view, we're a Microsoft Office/Exchange house, and all corporate software is done in-house with one exception: payroll is outsourced.  Every other department (A/P, A/R, HR, Bank, Purchasing, Sales & SFA, Product Entry, Training, etc.) [we] write, stage, and send to production, all custom-built and web-based.  All of the business rules are in the heads of existing staff members who have little or no time to disseminate the logic to other developers, plus, the logic is so spaghetti-complex -- in most cases -- that touching one page reaches accross many core operational modules.  You can't say that we're not re-using code here, but every ASP page has ten include files in it's header, and, most of these include files, have embedded inlcude files in them too.  It's not extraordinary for Includes to nest 2-, 3- or 4 (sometimes 5) levels deep, Aaaargh!!

We have ~37 core business components (that I have been able to ascertain; which could be migrated to less than 15 total if properly re-written), but the one I'm contemplating/focusing on right now consists of these files/types:

TYPE  # FILES
----  -------
asp   1,204
inc   73
html  55
js    50
swf   19
htm   15
xml   9
txt   9
asa   7
xsl   4
class 3
bin   2
jar   2
xsd   2
dtd   2
pl    1
java  1

The above list is JUST the required files for this "one" component to function properly, minus the graphics/image files.  There are ~480,000 lines of code in the above, not including comments nor white spaces nor blank lines.

Several years ago, the company decided to migrate the primary retail portal to .Net technology.  Myself and the other "current .Net" developer are still trying to get the out-sourced code to staging; 24 months past deadline, we're 99.999% there.  Then, out of the clear blue sky, marketing decides they want a plethora of changes, made to already broken or disfuntional code, and we're in the hole again.  Plus, management is giving core projects to ASP developers whom have never even read a .NET book! , let alone can they open a file in VS 2005!!  Double Aaaargh!!!

On the one hand, I've verbally committed myself to a year, and, if we get this done, will look good -- no, Great! -- on a resume.  On the other hand, I feel like I'm on a sinking ship and the Captain's on shore laughing.  I get the gut feeling that [their] sense of job security outweighs the tasks at hand, and [they're] looking for scapegoats.

Any and all inputs greatly appreciated.

"On the one hand, I've verbally committed myself to a year, and, if we get this done, will look good -- no, Great! "

Or, you will be the scapegoat for the whole thing.

Although you've verbally committed for a year, I can only presume your contract allows you to give notice and leave. If you haven't got the buy in and support from someone with the power to stop these "goings on", you're paddling up a waterfall. I would write a strategy, present it and then make a decision based on "buy in". If they're willing to SIGN up to the strategy you could decide to stay - otherwise....

Thanks Sohnee for the quick feedback ;)

Per your "sign up" recommendation, and, although already tried, I'll re-tool, and try that again.  BTW, I verbally committed to 1 year, and am salaried ;)

The alternative, if you're stuck with that comittment is to be a "company man" for a year - do it all however they want it done with plenty of documentation to show your warnings and recommendations so you're covered when it all goes wrong. The philosophical view sometimes has to be taken that there can only be one "technical lead" on a project and in this instance, it clearly isn't you as they won't listen to you.

Point well taken! 

I am (we are) doing exactly that: documenting everything, and, additionally commenting where -- if we'd used alternative's -- we would have saved time (and money).

 On a sidebar: do you have any links, white papers, or other references to nightmare migratons, what went wrongs, etc.?

 Thanks again,

This really is a great article for that - it's more general, but the comments on migration are good.

http://www.dulcian.com/papers/Top%2010%20Reasons%20Why%20Systems%20Projects%20Fail.htm

Great article!  Keep 'em coming :)

MioTEK:

On the other hand, I feel like I'm on a sinking ship and the Captain's on shore laughing.  I get the gut feeling that [their] sense of job security outweighs the tasks at hand, and [they're] looking for scapegoats.

I've been a programmer for 25 years and worked in a variety of places, good and bad, as a contractor and an employee.  I used to think that I had to stay somewhere at least a year or future employers would look askance at me.  I used to think that I, as an employee, had to uphold my end of the "bargain" even if my employer was not.

I now know that if you're in a bad situation, you should get out as soon as you can secure other employement.  No one will question why you left if you explain it honestly (believe me, almost everyone has been in a similar position -- you will be met with sympathy).  Prospective employers will respect you for saying that it became clear to you that this job wasn't working out, through no fault of your own, and you decided to cut your losses.

As to your promise to stay a year, this is a one sided promise.  Your employer made you an implied promise to treat you with respect and let you do your job professionally.  If they break that promise you are under no obligation to them.  Remember too that this is a very one-sided bargain -- they hold the cards since they have the money.  They have far more power in this relationship than you do.