Successful AWS file server migration | Operational criteria that planners should keep in mind

On-premise file servers are no longer an infrastructure that can be fixed simply by updating the hardware. With remote work becoming the norm, distributed locations, and information assets expanding, traditional scale and operational design is reaching its limits. The reality is that multiplexed backups and individualized authority management continue to strain IT department resources.

Migrating to AWS is not just about "cloudifying file sharing," but also about redesigning information governance, including permissions, inventory, and audits. Beyond comparing the specifications of the migration method (FSx/S3), planning decisions such as "who will use it, how they will use it, and to what extent they will manage it" will have a major impact on operational costs and results after the migration.

In particular, FSx is an option that allows for frictionless transition in the short term, while S3 is an option that is suitable for gradual inventory and strengthening of governance. Therefore, rather than choosing one or the other, a two-stage transition with different timing and use is the realistic solution.

This article is aimed at IT department planners and decision makers considering migrating file servers to AWS.

- Three points to consider before migration

- Common failure patterns and workarounds

- A two-step migration from FSx to S3

- The dividing line between post-implementation operational design and outsourcing

We will provide a practical explanation from an operational perspective.

Why migrate your file servers to AWS now?

The reality is that on-premise file servers are reaching their limits not because of a lack of spare parts or insufficient performance, but because of the difficulty in maintaining operations and governance. User working styles, site structures and the rate of data growth have outpaced the original design, making perimeter networks and traditional access models unsustainable.

It's not the "technical limit" of continuing on-premise, but the "operational limit"

Technically, it's possible to continue expanding the system while keeping it on-premise. However, the challenges lie on the operational side. This includes bloated permissions, inconsistent shared policies, and the dependency on individual personnel for access audits and log maintenance. Furthermore, adjustments are required every time a problem or update occurs, and conflicts with nighttime batch and backup processes become chronic.

This "time for management" keeps increasing endlessly, putting pressure on the work that should be done. The reason for choosing AWS is not because of its high functionality, but because it allows for operational redesign based on auditing, visualization, and automation.

Old designs are beginning to crumble due to decentralized locations and changes in the ratio of remote workers

The traditional "internal LAN-based + VPN connection" model is no longer compatible with work styles that assume constant remote connections and the use of SaaS. With the increasing use of remote editing and collaborative editing of large files, and sharing with overseas bases and external partners, the traditional design is always at risk of delays and disconnections.

Going forward, it will be necessary to ensure proximity between the cloud and ID management and shift to a design that assumes location-independent I/O patterns.

Backup/BCP redundancy is taking away "in-house IT work"

When trying to strengthen BCP and data protection in an on-premises environment, the burden of generation management, remote maintenance, recovery verification, and inventory increases, making operations more complex. The more devices and mechanisms are added, the more complicated the design, testing, and recovery procedures become, resulting in a paradoxical situation where the operational burden increases.

When migrating to AWS, backup (recovery) and DR (business continuity) designs are separated, and automated verification and recovery assurance are left to the "system side." This frees the IT department from work management and allows them to focus on policy-based operations.

The main methods available on AWS and their roles

When building a file server on AWS, the main options are "FSx for Windows File Server" and "Amazon S3 (with File Gateway)." Rather than comparing which is better, it's important to consider which is best suited to your usage pattern. In particular, the ease of implementation and migration burden will vary depending on the extent to which you want to maintain your existing permission system and access methods.

FSx for Windows File Server

High compatibility with existing ADs, minimizing transition friction

FSx is a native Windows file server, and is highly compatible with on-premises Active Directory environments. Its greatest advantage is that it inherits existing group policies and NTFS permissions, allowing migration without changing the user experience. There's also little need to retrain clients or change user etiquette, making it the easiest option from the perspective of "not stopping operations or making major changes."

In the early stages of migration, if you want to minimize the burden on your IT department without disrupting users, FSx is a realistic first step.

While authority design can be inherited, inventory tends to be postponed

On the other hand, the process of "taking over" also poses the risk of "putting off inventory." If the bloated authority and promiscuous group structure of the on-premise era are carried over as is, "technical debt" will remain even after moving to the cloud.

If you migrate without reorganizing your permissions system or redefining operational policies to reflect actual usage, the burden of future security reviews and inventory will increase. FSx is ideal for a "soft landing," but becoming fixed in place as is can be a pitfall.

Amazon S3 + File Gateway

Cost optimization for archives, infrequent use, and shared areas

Amazon S3 has no capacity limits and allows you to flexibly select storage classes based on access frequency, making it suitable for optimizing archiving and long-term storage space. By using File Gateway in conjunction with Amazon S3, you can maintain the same UI/UX as traditional file access while storing the actual files in Amazon S3. It also works well with cloud services in terms of permissions and SaaS integration, making it more suitable than FSx for low-cost, secure storage of files that are not frequently opened but cannot be deleted.

This is the most effective landing point for data in the middle range where "it's too much for FSx" and "it's risky to keep it on-premise"

Easy to transition and organize in stages

Another feature of Amazon S3 is that it makes it easy to initiate migration (i.e., inventory). Unlike FSx, which is designed to inherit existing permissions as is, organization naturally occurs at the stage of deciding "which data should be placed in which class."

It is suitable for a design that does not require a sudden full migration, as it can be achieved in stages with "first migration from cold areas" in the short term, "elimination and consolidation of unnecessary areas" in the medium term, and "lifecycle operation by department/use" in the long term. In particular, S3 + File Gateway is a good match for solving the problem of "left-behind data" that has been accumulating for many years in on-premises assets.

Combining FSx and S3 (tiering)

Production operation → FSx / Long-term storage → S3

The combined model is designed to divide roles between FSx and S3. FSx maintains high-speed, low-latency access for files used daily or frequently updated, while offloading files that are accessed less frequently and archived data to S3.

Rather than "everything on FSx" or "everything on S3," tiering according to access characteristics makes it easier to achieve both performance and cost. In particular, in environments with a few TB to tens of TB, tiering can simultaneously optimize initial migration costs and long-term operating costs.

Effective as a "realistic transition model" rather than an idealistic one

In an actual migration project, neither a sudden major reorganization nor a quick migration to S3 will suit the situation on-site. In many cases, the most realistic approach is to first achieve a non-disruptive migration with FSx, and then gradually offload data to S3.

This is not a theoretical best practice, but an optimal solution from a practical perspective that allows migration, inventory, and operational establishment to be parallelized without difficulty. When considering operational continuity after cloud migration, using both systems is the least likely to fail and is a design that is easy for the field to adopt.

Three points to consider before migration

Before choosing a method, it's important to clarify the perspective of "what kind of usage will be supported by what operational model?" File server migration is not simply a technology selection; it begins with a "planning decision" that determines three things: users, permissions, and operational structure. If you decide on a method without clarifying this point, it can lead to liabilities after the migration, such as "high functionality was selected but is not used," "performance requirements are not met," or "inventory is never completed."

The three decision criteria explained below are prerequisites that should be decided before deciding which method to adopt. By clarifying the design perspective, it becomes easy to decide whether FSx, S3, or a combination of the two is appropriate.

①User characteristics and access requirements

Number of locations, VPN routes, and update frequency

The first thing to check is "where is it being accessed from and how frequently?" If you have many locations and constant connections via VPN routes, on-premises latency design can easily reach its limits. Especially in areas where there are a lot of daily updates or cross-departmental collaborative editing, high-speed access close to the cloud, like FSx, is advantageous.

Conversely, if the area is primarily used for reference and search and is updated extremely infrequently, offloading to S3 will be more effective in terms of both cost optimization and operational simplification.

File size/I/O trends

The size of the data you are handling and the I/O patterns are also important factors to consider. For data that is large in file size and requires frequent editing and opening, such as CAD or video, FSx is suitable to minimize latency.

On the other hand, data that is "reference-centric" and "storage-priority" such as documents, designs, and contracts is compatible with S3 and is highly compatible with cloud-native workflows (permission management and lifecycle operations).

Typical cases for choosing FSx / Typical cases for choosing S3

By clarifying the criteria for judgment, the following practical divisions are clear:

This decision should not be based on technical "preference," but should be determined by working backwards from the actual usage and I/O. If you get this wrong, no matter how high-performance the configuration you choose, it will end up being a mismatch that "doesn't suit your purpose in the first place."

②Authority model and inventory granularity

Porting (following the status quo) leaves behind "technical debt"

FSx can inherit existing AD and permission settings almost as they are, making it extremely convenient from a "one-time migration" perspective. However, this advantage can also create the problem of "postponing the review of permission structures." In reality, there are many areas where it is unclear who has what level of access, with traces of past organizational changes and departmental mergers and abolitions still remaining.

If you bring this system over to the cloud as is, it will become more difficult to organize it later, which will lead to failure where governance does not improve despite moving to the cloud.

The key is to take inventory → abolish/consolidate → transition

The appropriate procedure is to "first take an inventory, then eliminate and consolidate unnecessary areas, and finally migrate." Rather than designing with the premise of "maintaining the environment" as was the case in the on-premises era, the perspective of using the migration as an opportunity to reorganize information assets is required. In particular, if the inventory is postponed, the decision of "which is FSx and which is S3" will become unclear, and the cloud architecture will not be optimized. It is no exaggeration to say that the success of the migration is determined not by the technology but by the "degree of completion of the inventory."

Folder-based vs. group-based inventory lines

The granularity of the inventory is also important. The workload and migration speed will change depending on whether you organize by folder or by access group. If large-scale permission updates are involved, organizing by group is easier to control, while long-term storage areas (potential S3) tend to be easier to disassemble and delete by folder.

Rather than choosing one or the other, the key is to select the granularity that matches your operational design after migration, such as "group-based on the FSx side" and "folder-based on the S3 side."

3) Operational structure (in-house/outsourced)

AD/FSx/S3 Responsibilities

After migrating to the cloud, it is necessary to redefine the scope of operations and division of responsibilities. While on-premises systems typically involve in-house management of each server, on AWS the roles of ID management (AD), file services (FSx), and storage infrastructure (S3) are separated. As a result, it becomes easier to clarify the extent to which in-house IT will handle operations independently and the extent to which external operational support will be utilized.

If the migration is carried out without clarifying this point, practical tasks such as responding to inquiries, isolating problems, and changing settings will remain personal, and the cloud migration will end up resulting in ``dual management of operations.''

Management tasks such as operational monitoring, quotas, and audit support

After migrating to the cloud, the importance of back-end management tasks increases, such as monitoring, capacity management, quota settings, access log acquisition, security reviews, etc. Unlike on-premise systems, equipment maintenance is no longer necessary, but the focus shifts to "governance-enhanced operations" such as policy operation, log visualization, and internal control.

In this area, it is possible to reduce labor costs by systematizing and automating the process, but on the other hand, "if left ambiguous, it is likely to become a mere formality," so it is important to determine in advance whether a dedicated person or specialized vendor will be involved.

The best solution is a hybrid of in-house production and outsourcing of maintenance.

In practice, the best approach is a hybrid model in which the "construction-related areas" such as requirements definition, inventory, and deciding which areas will be included in which services are done in-house (or by a partner in a similar position), while the operational establishment, audits, and continuous improvement are outsourced.

In cloud operations, the performance indicator is closer to "establishing governance" than "owning the technology," so by putting in place a framework that provides support during the operations phase, the IT department can focus on its core planning duties.

Common failure patterns

The success or failure of a file server migration depends not so much on which service is used, but on the assumptions that were used in the design. However, in many migration projects, discussions stop at the stage of selecting the method and making estimates, and considerations necessary for the actual operation phase tend to be overlooked. This leads to failures such as "the burden does not decrease despite the migration" or "in fact, the design becomes too complicated to handle."

It only compares the functions and does not go as far as comparing the operations.

Simply reading the documentation for FSx and Amazon S3 and comparing performance and pricing tables won't lead to the right decision. The important thing is to consider what will happen after deployment. For example, updates, audit support, accountability to user departments, and lifecycle management. If you decide on the method first without considering these things, the operational burden after migration will remain the same, and the value of cloud migration will be halved.

"Copy" the transfer of authority and postpone inventory

If you prioritize "not stopping the migration" and keep existing permissions as they are, you will miss the opportunity to take inventory forever. Even if you try to correct it later, it will be difficult to do so once usage conditions have changed, and you will end up with a "cloud without inventory" situation. In practice, the success rate is measured by the degree to which the inventory is completed, rather than the migration itself.

Mistaking Amazon S3 for a "cheap storage space" and ignoring performance requirements

While Amazon S3 offers low cost and strong durability, it is not suitable for areas with frequent editing or large volumes of sequential access. If you migrate without considering I/O requirements, the latency that was eliminated with FSx will become a bottleneck, resulting in a counterproductive outcome: "It was supposed to be cheaper, but it's also less user-friendly." Amazon S3 needs to be understood as a lifecycle platform, not a storage solution.

Migration while blurring the distinction between backup and DR

In on-premise operations, backups tend to be treated as BCP, but in the cloud, the roles are different. Backups are for preservation purposes for recovery, while DR is an alternative site or system for business continuity. If you migrate without clarifying this point, there will be a discrepancy between expectations and reality in the event of a failure, making it difficult to explain to management. It is important to design in a way that distinguishes between "restoring" and "not stopping."

How to proceed with AWS migration

File server migration is not a "task" but a "decision-making process." By clarifying the purpose, target, and operational structure of the migration before proceeding to select a method or service, you can establish a "sustainable" approach rather than just creating it and leaving it at that. Below is a standard approach to avoid failure in practical projects.

Step 1: Current inventory (area, authority, and usage status)

The first step is to take a rough inventory of the existing environment. Which department uses which area, who has been granted access privileges, and what are the actual update frequency and I/O trends? If you start the migration without understanding this "actual usage," you won't be able to decide how to divide the roles between FSx and S3. Areas that haven't been maintained for many years are more likely to become debt, so organizing them here is key to preventing reversal.

Step 2: Two-stage plan: short-term (FSx) and medium-term (S3 layering)

If you aim for complete optimization all at once, the field will not be able to keep up. A more realistic approach is to first move to FSx in the short term to achieve a "non-stop migration," and then gradually offload to S3 in the mid-term. This allows for a design that "organizes while operating," and allows for parallel inventorying, preventing migration stalls.

Step 3: Finalize the method based on user requirements and operational structure

The method selection is determined not by comparing features, but by the user requirements of "who will use it, where from, and how frequently," and the operational structure of "how much in-house care will be provided." At this point, the final decision on FSx/S3/combined use is made, and the cloud configuration is defined based on the "operational assumptions."

Step 4: Select DataSync/AD integration

The next thing to consider after the migration method is the migration method (DataSync/file copy tools) and authentication integration (AD integration). Both are not "goals" but "means to support migration and operation," and deciding on them too early can lead to setbacks. By making your selection at this stage, the design and method will naturally align.

Step 5: Decide on the post-migration "operational view"

Finally, define the operational view of "what to look at and maintain" after the migration, including post-migration monitoring, inventory cycles, log checking, governance, etc. It's too late to think about this after the migration, so by deciding this in advance, the migration becomes the starting point for operational design.

Only when you have defined it to this extent will your cloud migration be something that you can use and continue to use, rather than just moving it.

Operational design with post-implementation in mind

Cloud migration is not just about "building it and then being done." Rather, the outcome depends on how you handle audits, inventory, permission management, and log operations after going live. While on-premises systems focus on "maintenance," AWS requires "continuous control and optimization." Here, we'll summarize the operational aspects you should keep in mind after migration.

Permissions and auditing (IAM integration/access logs/quotas)

In the cloud, permission management is directly linked to "evidence and auditing" rather than "configuration." IAM integration centralizes authentication and automatically collects access logs, but "hands-off management" is only possible once auditing and quota operations are systematized. Permission and auditing operations based on visibility are fundamental to avoid reverting to the on-premises situation where "it's unclear who touched something."

Differences between backup and DR and realistic RTO/RPO

In AWS, the distinction between "backup = recovery" and "DR = uninterrupted system" is clear. Backup is suitable for preserving evidence and generations, while DR is a measure to ensure business continuity.

After implementation, it is important not to confuse these two, and the quality of operations depends particularly on whether the RTO (recovery time) and RPO (tolerable loss period), which serve as guidelines for restoring production, can be set within a realistic range.

"Operational design" for continuous inventory

Even if you organize your data through cloud migration, it will continue to grow. That's why it's important to incorporate post-migration inventory into your operational process, rather than treating it as a one-off task. For example, by regularly reviewing FSx space usage and automatically evacuating unnecessary space to Amazon S3, you can ensure a sustainable tiered operation.

The role of the IT department is shifting from "maintainer" to "governance"

In the on-premises era, the IT department was in a position to "maintain equipment," but after the transition to the cloud, its role changed to "protect information handling designs."

This does not increase the workload, but rather frees you from physical operations, allowing you to focus on higher-level tasks (security, audits, and internal rules). The shift in roles from technical "operators" to governance "designers" is the true value of cloud migration.

H2: How much is in-house? How much is outsourced?

Post-cloud operations are not a binary choice: "all in-house" or "all outsourced." In practice, it's easiest to strike a balance between workload and quality by clarifying what you want to handle in-house and what you want to entrust to external expertise. Below we've outlined three commonly adopted outsourcing patterns.

In-house construction only ⇒ Outsourced operation

The initial design and migration work is carried out in-house (or by a similar IT department), and then the subsequent operational aspects such as monitoring, backup confirmation, and initial troubleshooting are outsourced. This is a realistic, balanced approach that "removes only the operational burden" and is often adopted by organizations that want to "understand the intent of what they have created, while leaving the stable daily and monthly operation to someone else."

Support from inventory and design

This is a pattern in which external partners are involved from the inventory and design phases. In large-scale environments or complex authority structures, if the requirements definition is incorrect it is difficult to go back, so there are significant benefits to incorporating expert knowledge at this stage. If you are technically able to migrate but are not confident in the authority, inventory, or design aspects, it is better to have accompanying support from the very beginning to ensure that rework after migration is minimized.

Cases where monthly governance and inventory review are entrusted to the company

Cloud operations place a greater emphasis on "control" than "maintenance." As a result, there are increasing cases of outsourcing "continuous improvement" tasks such as inventory reviews and log audits. Third-party reviews ensure transparency at the internal control, security, and accountability levels, allowing in-house IT departments to function as "design owners" rather than "blockbuster players."

My Feelings, Then and Now

The success of a file server migration depends not on the "service selection" between FSx and S3, but on whether or not three points - actual usage, permissions, and operational structure - are properly organized. While on-premise environments can technically be extended, they soon reach their operational limits due to the dispersion of locations, data growth, and the increasing complexity of audit response. It is important to view migration to AWS as an opportunity to "redesign information management" rather than simply replacing it.

The most practical approach is to transition smoothly using FSx in the short term, and then gradually offload to S3 in the medium term. By assuming simultaneous use, you can comfortably balance performance, cost, inventory, and audits, and after the transition, operations will shift from "protection work" to "governance that maintains control."

Cloud storage has value if it can only be used.It only becomes meaningful when it is put into a form that can be operated continuously.