The best way to find possible problems with the ASA configurations is to use the "packet-tracer" command. This would tell you if some traffic is getting blocked by ACL or if the traffic is failing because of NAT
For a connection coming from behind "outside" you can use this format of the command
To test anything else you naturally just switch the "input <interface name>" to the one where the traffic is sourced from. You will naturally also have to check whether you need to use "tcp" or "udp" and also select a source/destination IP/port.
Taking the output of the following commands should help you to troubleshoot possible problems
You could take "packet-tracer" command output of both of the above mentioned cases. For example testing connectivity from "outside" to the "dmz" server. And the previous problem with testing connection from "inside" to "dmz" server.
If you are doing Dynamic PAT from "inside" to "dmz" then you should remove the above "static" commands that refer to "(inside,dmz)" then user wouldnt be able to connect from "dmz" to those "inside" IP addresses (of those static commands). This is the main reason why Dynamic PAT is not encouraged between local interfaces. It causes complexity for the NAT configurations when user have to add extra NAT configurations to override the possible problems caused by the Dynamic PAT
For the "management" interface you probably need any new NAT configuration.
The Dynamic PAT from "inside" to "dmz" means that you would need some Static Identity NAT configuration mentioned above also in the new software otherwise the ASA would drop the connection attempts.