This took some time to figure out.
I had 2 production instances, each with multiple portals. One instance was in a folder called /ASP and one instance in a folder /SECURE. Both were 6.x versions of DNN. The Primary Domain of the entire site is, hypothetically, domain.com. Child portals of BOTH /SECURE and /ASP show up as sub-folders within them. Their aliases include the child portal aliases domain.com/asp/childX and domain.com/secure/childY, for example.
Yesterday, as I mentioned in an unrelated post, I created two new test/dev instances of DNN 7.0.5, called TEST1 and TEST2. These were created in the same domain.com as /test1 and /test2.
Once TEST1 and TEST2 were tested and functioning as new out-of-the-box 7.0.5 sites, with new databases, I restored a copy of the data from the db for /ASP to the new db for test 1. .I (later) did the same thing, restoring the data for SECURE to test2.
During the install process the child portal default.aspx file from the new 7.0.5 instances [test1 and test2] crossed over and renamed/replaced the default.aspx files in ALL the domain.com/asp/childx and domain.com/secure/childy folders. [interestingly it still worked in a child folder]. Unfortunately it also renamed/replaced the default.aspx file for the main /ASP instance and the default.aspx file for the main /SECURE instance with this same "7.0.5 child portal file" [BAD in original post], which is a very different file... [GOOD in original post]
I found the cause and it was not a hack. I did not change all the portal aliases before I set the new 7.0.5 loose on the restored db... I was aided and abetted by the install scripts reaching out (crossing over) and mucking with my production instances... This just sounds wrong... I guess you can't cover for a bone-head admin...
Bob H.