Hi again @abjimenez. Sorry, I meant to reply like last time and apparently it was lost in the shuffle (tabs) before I hit the submit button.
Last time, I was saying that I was going to delete the stack and try it again. And I am back to report that I did it and it worked as you said. I tried to figure out what possibly could have happened. One thing I have noticed is that, when I launched the stack originally, I had updated the VPC to let the LB accept 0/0 (instead of the default local: once again I strongly suggest that this is the default behavior). So after migration, I attempted to go back to the original state by updating the stack again. This probably (shouldn't or something was missing) was the source of error. I couldn't find another reason why this should work this time.
So, I launched a new stack again. Went smoothly. And the admin console loads much faster. Recall that during the earlier attempt, the admin console was loading very slowly and was throwing a lot of errors even with clean installation (pre-migration) and got worse after the migration. This time it working reasonably well. I want to report that this problem has been resolved and I want to thank you for your help. I really appreciate it.
So here is my 2 cents as a suggestion for the stack
1) make LB default public (You actually give instruction to make it public: I am just thinking it's used mostly as public-facing anyways and some of us have problems reading instructions :))
2) LEMP instead of LAMP:
3) CFT Parameter to let users pick EFS IOPS provisions
4) CloudFront & S3 integrations would be awesome
Once again, thank you for your help.