Tl;Dr
So this happens to be more of a security answer than a compatibility answer.
The quick rundown on compatibility is that if you rely on AD user auth that will break, but if you use SQL Users and anonymous/some sort of local web auth special to the site, then you should be fine to join whenever you want.
On the security side of things; centralization reduces human mistakes, technical debt, surface area for attack, and increases visibility, ease of use, and security.
Security
If you have servers, joining them to a central management system is very important for ease of management, centralization of identity, and audibility.
Central Identity
Having identity islands is a security risk, because when an employee leaves, you will need to cycle/disable the credentials manually on each island, this increases risks of outages (acuidential rotation of non targeted credentials), forgotten rotation (missed an island) and more.
If you get hacked, the bad guy can hang out on a single island and mount attacks from there. After the bad guy gets a hold of more islands it becomes many times harder to eject the attacker from the many identity providers. You would essentially have to go to every machine and investigate each separately as a separate system. This is a very difficult process and bad guys can take advantage of how long it take to investigate and remediate to regain control on systems that they have been ejected from.
Identity centralization is a critical for organizations.
Audit
The ability to audit (gather system logs) your systems is also a hugely important security factor. Without a central management system, this critical security step is very difficult.
Without the ability to see what is happening on your system prevents you from effectively securing it as you can't see what the bad guy(s) are doing on it. You can't eject them, you can even see them on your computers. This is actually so bad in the industry that it takes on average 1 year before an organization finds out that they have been compromised AND it has bade the OWASP Top 10 list.
Management
On the manageability side of things, misconfigurations are a huge security risk.
They are so bad that they have made the OWASP Top 10 list.
To reduce risk of misconfigurations, centralization of configuration management is critical.
It reduces the chance that a human will make a mistake on configuring the required settings or that the setting would never be set.
A central configuration management system also makes it easier to push commands to endpoints to remediate compromises.
A good management engine can also produce audit data (logging) to give more visibility on what is happening in your environment.
Compatibility
the main things to look out for is the authentication system, if you use Windows Server AD to authenticate, you may have issues, if you use SQL Local users (insecure) then you should be fine on the compatibility side of things.
As long as the namespaces that you will join the machines to is available and your GPOs don't conflict with the needed web server and DB settings, you should be good.
With limited environment knowledge, it isn't easy to find edge cases. Generally speaking, you should be good to go.
Potential edge case:
if you have FQDN fanciness in your web app, domain joining your machine may change its FQDN.
Links
