Corporate e-mail setup is not just opening a new account for a business using an existing e-mail system. Continuing daily correspondence, keeping past messages accessible, preparing employee devices, and working on application submissions must be addressed together. Therefore, when purchasing an installation service, it is necessary to discuss the project's boundaries and acceptance method before the platform name. The price given may be based on incomplete assumptions without clarifying what outcome the business expects.
In this guide
- The first input of the quote is the current system inventory
- Don't limit the new account structure to old habits
- Define data migration scope by item type
- Pilot study tests assumptions early
- DNS change is a controlled project step
- The transition window and the decision to return should be discussed from the beginning
- User devices and business applications are part of the delivery
- How should project acceptance and first-term support be?
- How can you submit your installation request to İz Medya?
- Related resources
- Official sources
- Frequently Asked Questions
This article was prepared for companies that want to switch from a working e-mail environment to another. Unlike the scenario of opening an account from scratch, there is existing data, habits and dependencies. The aim is not to promise absolute uninterruption, but to determine in advance what will be checked during the transition. A good service scope explains who will make decisions in an unexpected situation as well as planned operations.
The first input of the quote is the current system inventory
Listing the number of accounts is a start; but it is not enough alone. Determine each account's approximate amount of data, private folders, local archives if any, and devices used. Write department addresses, directions, and auto-replies separately. It is also important whether you have administrative access to the old system. The capabilities of the source environment may affect the transfer methods that can be applied and the workload of the project.
Confidential access information does not need to be distributed in a common file when preparing the inventory. Account types and approximate sizes may be sufficient at the initial offer stage. When technical review is required, determine who will provide access, with what authority, and for how long. The person who manages the domain name and DNS should also be involved in the process. This way, it won't be obvious that a required access is missing on the day of the transition.
Don't limit the new account structure to old habits
A moving project can be an opportunity to realize the confusion that has accumulated over the years. But don't use it to make bulk changes without approval. The company must approve which addresses will be protected, which will be forwarding only, and who will access which public addresses. Changing the addresses used by employees may affect customer communications. For this reason, the address plan should be a joint decision of the technical team and the business.
Request an account matching table from the service provider. A table showing which new address the data from the old address will be transferred to and which name users will log in with will reduce confusion. If options such as nickname, group or shared access are to be used, it should be explained what need they meet. The usage and license conditions of each method must be verified separately on the selected platform.
Define data migration scope by item type
Ask what “all emails will be migrated” means. Are only messages on the server included or are archives on the employee computer also included? How will contacts, calendars, and task records be handled? The transfer method can support different data types depending on the source and target platform. It should not be assumed that a method carries all elements in the same format. Excluded items must be clearly stated at the proposal stage.
Also learn how to track transmission on large mailboxes. Which accounts have transactions completed, which have errors, and how will erroneous items be reviewed? It is more useful to see account-by-account status information rather than just an overall success message. However, not every error may mean data loss; The technical team should explain the finding and work with the business to determine how to proceed.
Pilot study tests assumptions early
A pilot study can be planned with a representative user before affecting all employees simultaneously. This user doesn't just have to be the person with the smallest mailbox. An account with folders, devices, and public address access that represents day-to-day operation may be more useful. The scope of the pilot, the transfer method to be applied, and the controls that the business will approve should be written in advance.
In addition to sending and receiving, access to historical data, device usage, and user experience should also be examined as a result of the pilot. A difference that arises may not require the entire migration to be done the same way. Ask the service provider to explain the finding, its impact, and the proposed change. This way, the project plan can be updated based on results seen in the real environment, not guesswork. Also clarify whether the pilot is included in the pricing.
DNS change is a controlled project step
Existing DNS records should be inventoried when connecting the domain name to the new e-mail infrastructure. It is not right to change website records indiscriminately due to e-mail work. The technical team should explain which record will be changed, for what purpose, and its impact on existing services. If change authority and business decision authority are held by different people, the approval process must be completed before transition.
The Google Workspace documentation describes editing MX records so that incoming email reaches the target system. Microsoft also documents the DNS and sender verification steps in the domain connection. However, instead of copying the same values for each company, the information provided by the platform used for that account should be taken as basis. Website forms and other submission sources should also be checked separately in the new layout.
The transition window and the decision to return should be discussed from the beginning
The day of the transition should not be determined solely by the vacancy of the technical team. Share business calendars such as accounting closing, busy order period or important customer meetings. Determine when employees will be notified and which communication channel to use in case of a problem. Some users working in the field or on a shift schedule may also affect the schedule. It should not be assumed that everyone will be in front of the computer at the same time.
Write down the circumstances under which an unexpected outcome would occur and who would decide. The rollback approach should not be reduced to just a record change; The status of the messages that may occur in the two environments at that time should also be evaluated. Ask the provider to explain how to handle this scenario. The existence of a plan does not guarantee that every problem will not occur, but it reduces the guesswork of making decisions under pressure.
User devices and business applications are part of the delivery
Just because the new environment runs on the server doesn't mean it's equally ready for employees on their own devices. Clarify what actions will be taken for desktop programs, phones and public computers. It should be determined whether device installation will be performed remotely or on-site and when users must be present. If the offer includes only management panel installation, device support may be priced separately.
Also test messages sent from applications such as accounting software, websites, and browsers. If these systems are connected to the old account, they may require changes with the new order. The responsible person for each application should be included in the project. The email service provider may not be able to access all settings of another software. Therefore, knowing the dependencies and the involvement of third parties from the beginning ensures more orderly delivery.
How should project acceptance and first-term support be?
The acceptance list should be based on functional results. Selected users' attempts to send and receive messages with different external addresses, control of access to common addresses, and review of sample history messages may be included in this list. It should be recorded in which accounts the checks were made and how the deficiencies found will be monitored. If the company's approval person is determined, uncertainty about the conditions under which the project is completed will be reduced.
Also find out the duration and scope of initial support. A deficiency discovered during the transition may not be the same as the new feature requested later. Ask the provider to write down this distinction. When the project is closed, administrator access, account inventory, a summary of changes made, and a list of work in progress should be delivered to the company. Thus, the daily management of the system does not depend on personal memory.
How can you submit your installation request to İz Medya?
Share your current platform, number of users, approximate amount of data, and your targeted migration period. Also specify which devices users are using and the business applications that send email. For uncertain information, simply write that you are using an estimate. Asking for installation and transportation to be described in separate items makes the scope of the quote more readable. Do not share passwords in an initial conversation or open form message.
Mail transportation service and scope of corporate e-mail infrastructure you can review. When contacting İz Medya Specify specifically that you want to switch from your current system. Thus, a project discussion can be held that includes not only account opening but also data migration, device preparation, acceptance control and support limits.
Technical references: Google Workspace MX records; Microsoft domain link.
Related resources
Official sources
Technical documentation and legislation may change; The relevant version and current text should be checked before application.
Frequently Asked Questions
What steps does the transition from the current system to corporate e-mail setup include?
Account and data inventory, new address matching, pilot study, data transfer, DNS change, device preparation and acceptance tests are planned. The transfer scope of each data type must be verified separately.
Does the installation service include migration of all old data?
It does not cover itself. Messages, local archives, contacts and calendars may require different transfer methods. The types of data included and excluded in the proposal must be clearly stated.
