On the day after closing, the organization notices the difference between a deal on paper and a deal in practice mainly through access. Can someone log in. Does the badge work at the door. Does the payment go through. This section addresses that question, separate from the question of what gets communicated or who decides — that is described at what you communicate on Day 1 and at who has decision-making authority on Day 1. Here the focus is on the list itself: which types of access, and why those specifically.
Arranging access is not a synonym for integrating. An employee who can log in on Day 1 to the system they already used has not been integrated — they have simply kept working. That distinction matters, because the pressure to do everything at once is significant around a closing. The question that should be asked for every type of access is not only "does this work", but also "does this ultimately need to be merged, or can it keep functioning separately". A shared email system is sometimes needed for Day 1, a shared ERP rarely. Whoever lets these two run together creates work that was not necessary and risk that could have been avoided.
The core is simple to state and difficult to execute: everyone who could work yesterday must be able to work today. This affects email, the primary business system, shared drives or cloud environments, and any customer systems that employees use daily. In an acquisition, ownership of accounts, licenses, or domains often changes, and this can block access without anyone having foreseen it beforehand. A list of systems per job group, with a status per system — stays, changes, gets replaced — prevents this from coming to light only on the day itself.
Badges, keys, security codes, and visitor registrations are easy to forget because they are so self-evident, until they are not. In an acquisition, management of a building can transfer to a different entity, causing existing badges to become invalid at a moment no one was expecting. This also applies to warehouses, production sites, and server rooms. The question here is not only technical but also practical: who holds the key to the key cabinet at the moment it matters.
Payroll, payments to suppliers, and the collection of customer invoices should not come to a halt because a legal structure has changed. Bank accounts, signing authority, and payment systems require attention around the moment of closing, and the details of this are connected to the legal form chosen after the transaction — that connection is described at the legal form steps that belong to Day 1. In an acquisition with a cross-border character, additional complexity is added around currency, local banking relationships, and regulation, which is worked out separately on the page about what happens to payments on Day 1 in a cross-border acquisition.
Not only internal employees need access. Customers who log in to a portal, suppliers who submit invoices via a system, partners who use a shared platform — for them nothing may visibly change on Day 1, and that is usually the goal. Where that does not succeed, the risk arises that the first experience with the new owner is a disruption. Contracts that govern access rights deserve attention for this reason around the closing itself, which touches on the question of which agreements need to be reviewed again at that point — see which contracts require Day 1 attention in a cross-border acquisition.
The value of this section does not lie in the idea that access is important — everyone knows that. The value lies in recording every type of access as a separate line item: who needs it, which system or space it concerns, what its status is at this moment, and who is responsible for the handover. Without that list, access becomes a collection of separate issues that surface on the day itself, with little time to resolve them. With that list, it becomes a verifiable part of the Day 1 plan, linked to the broader question of what needs to be arranged on that day — including in acquisitions with an international component, as described on the page about what needs to be arranged on Day 1 in a cross-border acquisition.
Not every type of access that exists today should still exist in the same form tomorrow. Some systems are eventually merged, others remain deliberately separate, and part is phased out because it has become duplicated. That distinction should not arise spontaneously during execution, but should be on the decision list beforehand: integrate, do not integrate, or still to be determined. Arranging access for Day 1 and deciding on merging in the longer term are two different questions, and it is advisable to treat them as such.
Mapping every type of access, every system, and every handover is itself a form of work, and part of it is repeatable enough to automate. The work scan from FTE TO AI calculates per task which portion of that work can be taken over by AI, which is helpful for those who do not want to draw up these lists for the first time without any starting point.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.