Switched BizTalk's database domain, but cannot remove DC

I've inherited an older system involving BizTalk (Server 2010) where the application and its database were on separate servers on separate domains.

There has been efforts to modernize the systems and applications, and I had to roll with it when the databases were upgraded from SQL Server 2008 to 2017. I thought it would reduce complexity if we at the same time moved the database from its domain to join the same domain that the application is in. Since it was the last artifact on the domain, we could then also remove the domain controller (theoretically.)

The database move happened in production, and it impersonates the older version so that BizTalk Server 2010 can still access it, and the application works - and this delighted me.

However, we attempted to remove the domain controller for the domain where the database lived before, and the application then failed saying it could no longer authenticate with the database. Upon turning on the domain controller, it started working again.

I have looked at what I believe are the BizTalk application settings and the database settings from SSMS, but I have no idea why there is still dependence on the domain controller we left behind. I have to assume previously, since the application and database lived in different domains, to get it working correctly there was some form of trust set up between the domains.

I have no knowledge of the domain controllers nor have access to them or their active directory. I need some direction and have searched the web a few times when I can, but to no real avail.

I figure it is either something I missed on the database or application end that I can still fix, or that it is involved with the configuration of AD on one or both domain controllers. If the latter is the case, then I need to know what to ask of the company's IT group to check, as they believe it is an application issue and are not being further helpful without specific details.

The business is leaning on me to do away with the older domain controller. What ideas are out there with regards to solving this?

This was originally asked on Stack Overflow (as I am a developer) but it didn't meet their guidelines and they suggested I post here instead. I had one response at that time, a helpful person who suggested I look for the old domain name using a search through the text of all tables of the BizTalk Management Database. I went through each one, and didn't find any references to the old domain name here. Hopefully that will help focus forthcoming assistance.

This is no longer applicable as the company decided to abandon its solution and go with a new, hastily-put-together new solution involving different technology.

The answer in this case would be for companies to accept that migrations to new versions of operating systems and middleware is a good thing and will prevent people trying to cobble together unsupported server migrations using unsupported software and running into problems.

I honestly think, despite the effort involved in a proper BizTalk upgrade, that it still would've taken a shorter amount of time to perform the upgrade than it would have taken to create the new solution, and they would have had all the features they had to drop to make this happen.

Thank you all for your comments - much appreciated.