Glossary

An Access Control List (ACL) is an ordered list of access control entries (ACEs), each granting or denying a specified set of permissions to a specific user or group identity on a file, directory, or other securable object. Its purpose is to provide a granular, flexible access control model that enables administrators to define distinct permission sets for multiple named principals on a single resource — going far beyond the three-class owner/group/other model of POSIX permissions. On Windows NTFS and Windows-compatible NAS systems, ACLs are the primary access control mechanism. Faithful ACL preservation during NAS migrations is one of the most complex and consequential aspects of migration execution, as ACL errors can render data inaccessible or expose it to unauthorized users on the target.

ACLs are defined in POSIX.1e (for Unix/Linux), the Windows Security Architecture (for NTFS), and NFSv4 RFC 7530 (for cross-platform NFS ACLs). Incorrect ACL handling is the most common cause of post-migration user access failures and represents the highest technical risk in enterprise NAS migrations.

StorageMAP’s ACL-aware migration engine correctly handles all six NTFS inheritance flags, compound ACE types, and SID translation in a 4-million-file migration, resulting in zero post-migration access complaints — compared to an earlier rsync-based migration at the same organization that generated 200+ helpdesk tickets from users unable to access their files.

Active Directory (AD) is Microsoft’s enterprise directory service for Windows domain networks, providing centralized management of user accounts, group memberships, computer accounts, and security policies through a hierarchical LDAP-based directory and Kerberos authentication infrastructure. Its purpose is to serve as the single authoritative identity and policy store for Windows environments — issuing SIDs to all principals, enforcing group policies across domain-joined systems, and providing Kerberos tickets for authentication. StorageMAP integrates with Active Directory via LDAP for user authentication, and the AD domain structure of source and target environments is a critical input to SID mapping configuration for any SMB migration that crosses a domain boundary.

Active Directory was introduced with Windows 2000 Server and now manages identity and access for the majority of Fortune 500 companies globally. Azure Active Directory (now Microsoft Entra ID) provides cloud-based AD functionality and is the most widely deployed cloud identity platform.

A company migrating from its legacy on-premises domain to a modern Azure AD-joined domain uses StorageMAP’s SID mapping capability to translate all file system ACLs from legacy SIDs to new domain SIDs during the NAS migration, completing the identity transition without any manual ACL remediation on the new file server.

Agentic AI refers to AI systems — typically built on large language models or small language models — that are capable of autonomously planning and executing multi-step tasks by breaking down goals, selecting tools, taking actions, observing results, and iterating until an objective is achieved. Unlike single-turn AI interactions, agentic systems operate over extended time horizons and interact with external systems — databases, APIs, file systems, and storage platforms — to complete complex workflows without continuous human input. As AI agents are increasingly tasked with operating on enterprise data, the security, governance, and auditability of the underlying data infrastructure becomes critical.

Agentic AI frameworks — including LangChain, AutoGen, CrewAI, and Anthropic’s Claude in agentic configurations — are moving from experimental to production deployment in 2025–2026, with enterprises using agents for tasks ranging from customer service automation to autonomous code review and data pipeline management. The storage systems that agents access must be well-governed, since an agent acting on poorly controlled data can amplify data quality and security issues at machine speed.

An enterprise deploys an agentic AI system to automate data lifecycle management. The agent uses StorageMAP’s API to query the data catalog, identify cold data older than seven years, verify retention policy compliance, and trigger deletion or tiering actions — completing in hours a lifecycle management task that previously required weeks of manual review.

Apply the principle of least privilege rigorously to agentic AI systems — an agent should only have access to the data and actions it needs for its specific task. Instrument agent actions with full audit logging and require human approval gates for irreversible operations such as data deletion, regardless of the agent’s confidence level.

Amazon Elastic File System (EFS) is a fully managed, serverless NFS file system provided by AWS that automatically scales capacity up and down as data is added or removed, with no provisioning or capacity planning required. Its purpose is to provide a cloud-native shared file system for Linux workloads that need simultaneous multi-client NFS access — including web serving, content management, data analytics, and container-based applications — without requiring organizations to manage NAS infrastructure in the cloud. Amazon EFS is a supported StorageMAP NAS migration target for organizations moving Linux NFS workloads to AWS, offering a fully managed destination that preserves POSIX semantics and NFS protocol compatibility.

Amazon EFS pricing is capacity-based with no per-IOPS charge, making it cost-effective for workloads with variable I/O demand. EFS Standard storage costs approximately $0.30/GB/month, while EFS Infrequent Access is $0.025/GB/month.

A software development organization migrates their 50 TB code repository NAS to Amazon EFS using StorageMAP, enabling developers globally to mount the same file system from their EC2 build instances with identical POSIX permissions and consistent latency regardless of AWS region.

Amazon FSx is a family of fully managed, cloud-native file system services from AWS that deliver the features and APIs of industry-standard file platforms — including FSx for Windows File Server (SMB/NTFS), FSx for NetApp ONTAP, FSx for Lustre, and FSx for OpenZFS — without the operational burden of managing underlying storage infrastructure. Its purpose is to enable organizations to run enterprise file workloads in the cloud with full native protocol compatibility and feature parity for their chosen file system, eliminating the need to refactor applications or retrain operations teams. FSx for Windows File Server and FSx for NetApp ONTAP are the most commonly used StorageMAP migration targets within the FSx family.

FSx for NetApp ONTAP is unique among cloud file services in offering full ONTAP feature parity including SnapMirror replication, FlexClone, deduplication, compression, and multi-protocol NFS and SMB access. FSx for Windows File Server provides Windows-native SMB with Active Directory integration and DFS support.

A healthcare provider migrates 200 TB of clinical application data from on-premises NetApp FAS to FSx for NetApp ONTAP using StorageMAP, maintaining full ONTAP feature compatibility and enabling their clinical applications to run unchanged on the cloud platform.

Amazon Simple Storage Service (Amazon S3) is the original and market-leading cloud object storage service provided by Amazon Web Services. Its purpose is to deliver virtually unlimited, highly durable, and globally accessible object storage through a simple HTTP-based REST API that has become the de facto industry standard for cloud and on-premises object storage interoperability. StorageMAP uses the S3 protocol for all O2O migrations and treats Amazon S3 as both a protocol standard and a specifically supported platform endpoint, with S3 buckets serving as among the most common targets for StorageMAP cloud migration projects that move on-premises file and object data to AWS.

Amazon S3 launched in March 2006 and is now the world’s largest object storage service, holding trillions of objects and processing hundreds of billions of requests per day. S3’s HTTP REST API design was so successful that it became the universal standard for object storage. S3 offers 11 nines (99.999999999%) of object durability through automatic replication across multiple availability zones.

A global broadcaster uses StorageMAP to migrate 8 PB of completed programme archives from an on-premises Scality RING to AWS S3 Glacier, reducing annual storage costs by $2.4M while maintaining full metadata and object key integrity for their archive management system.

Amazon S3 Glacier is a family of AWS storage classes within the S3 service designed for long-term data archiving and compliance retention at dramatically reduced per-GB cost, at the trade-off of delayed or staged data retrieval. Its purpose is to provide an extremely cost-effective destination for data that must be retained for regulatory, legal, or historical reasons but is rarely if ever accessed under normal operating conditions. StorageMAP O2O migrations to AWS S3 can target Glacier or Glacier Deep Archive as the destination storage class for archive-eligible datasets, allowing organizations to implement a cloud archiving strategy as a direct outcome of the migration without requiring additional post-migration lifecycle rule configuration.

S3 Glacier Deep Archive at $0.00099/GB/month is the lowest-cost cloud storage available from any major provider, making it the standard choice for long-term compliance archives in regulated industries. The 12-hour standard retrieval time is acceptable for regulatory records that must be kept but are rarely retrieved.

A financial institution uses StorageMAP to migrate 20 years of trade records (4 PB) to S3 Glacier Deep Archive as part of an SEC Rule 17a-4 compliance programme, reducing storage costs from $1.2M per year (on-premises disk) to under $50,000 per year — a 96% cost reduction — while maintaining full regulatory compliance.

Amazon S3 Intelligent-Tiering is an AWS S3 storage class that automatically monitors object access frequency and moves objects between frequent-access, infrequent-access, and optional archive tiers based on actual usage patterns — with no retrieval fees, no performance impact, and no operational overhead for the managing administrator. Its purpose is to optimize ongoing storage costs for datasets whose access patterns are variable, unpredictable, or expected to change over time, eliminating the need to maintain manual lifecycle rules. In StorageMAP O2O migrations to AWS S3, Intelligent-Tiering can be set as the target storage class for datasets where future access patterns are uncertain, delegating ongoing cost optimization to the AWS platform itself.

S3 Intelligent-Tiering charges a $0.0025 per 1,000 objects monitoring fee but eliminates the retrieval fees associated with Infrequent Access classes, making it cost-effective for datasets with unpredictable access patterns. It is particularly well-suited for machine learning training datasets, which may be accessed intensively during model training phases and then lie dormant for extended periods.

A biotech company stores genomics datasets in S3 Intelligent-Tiering via a StorageMAP O2O migration, and finds that AWS automatically optimizes their storage costs based on analysis usage patterns — reducing their monthly S3 bill by 40% without any manual intervention after the initial migration.

Amazon Web Services (AWS) is Amazon’s cloud computing platform, the world’s largest by revenue and market share, providing over 200 fully managed services including compute, object storage (S3), managed file systems (EFS, FSx), databases, and analytics from globally distributed data centers. Its purpose is to provide on-demand, pay-per-use infrastructure that allows organizations to scale storage and compute capacity without capital investment in physical hardware. AWS is the most common cloud destination in StorageMAP migration projects, with S3, EFS, FSx for Windows File Server, and FSx for NetApp ONTAP serving as the primary AWS storage endpoints used as migration targets.

ΩAWS holds approximately 31% of the global cloud market (2024) and is the dominant cloud platform in enterprises, particularly in financial services, healthcare, and technology sectors. AWS’s storage portfolio covers every tier from ultra-low-latency NVMe storage to deep archive, enabling end-to-end storage lifecycle management within a single cloud platform.

An enterprise completing a data centre exit programme uses StorageMAP to migrate 15 PB of NAS data to a combination of AWS FSx for Windows File Server (for active workloads), S3 Standard (for active object data), and S3 Glacier (for archive), fully exiting on-premises storage over 18 months.

An Analysis is a flexible, interactive exploration workflow within StorageMAP’s graphical interface, used to examine and categorize data within a Scan Root. Its purpose is to help storage administrators understand what data exists, how it is distributed, and which subsets qualify for action — without requiring any code or query language. Users perform an Analysis by applying filters and classifiers in sequence, progressively narrowing the dataset until a targeted collection is produced that can be exported as a report or used as the input for a migration, move, copy, or deletion operation.

An IT administrator investigating storage growth starts an Analysis on a file server Scan Root, applies a filter for files not modified in 1,095 days (three years), then runs a Classifier that groups results by file extension. The resulting chart shows that 80% of the cold data is video files owned by a single department — a finding that takes minutes rather than days with manual scripting.

Self-service analytics reduces the dependency on specialist scripting skills and empowers non-technical stakeholders to participate in storage governance decisions.

An Approval Gate is a checkpoint embedded within a StorageMAP Workflow that pauses automated execution and requires a designated reviewer to examine the results of preceding steps and explicitly authorize the Workflow to continue before any irreversible operation is performed. Its purpose is to preserve human oversight and governance accountability within otherwise automated data lifecycle pipelines — particularly before Data Deletion or large-scale Data Move operations that cannot be undone. Approval Gates generate notifications to designated reviewers, present the precise data in scope, and record the identity of the approver and the timestamp of the sign-off as part of the Workflow audit record.

A legal department requires that any deletion of files tagged Litigation-Hold must be reviewed and signed off by the General Counsel before execution. StorageMAP’s Approval Gate pauses execution and emails the GC a summary of files in scope for review. The GC’s approval is recorded with a timestamp in the Workflow audit log, providing a defensible record if the deletion is ever challenged in court.

Approval Gates implement segregation of duties — a requirement of ISO 27001, SOX, and PCI-DSS — within automated data management workflows.

Archive storage is the lowest-cost, highest-latency tier of a tiered storage architecture, designed to retain data that is rarely or never accessed but must be preserved for regulatory compliance, legal hold, historical analysis, or long-term business continuity. Its purpose is to provide a cost-minimizing retention layer that satisfies preservation obligations at a fraction of the per-TB cost of primary or secondary storage, accepting retrieval times measured in hours or days as the trade-off for dramatic cost reduction. In cloud environments, archive tiers include AWS S3 Glacier Deep Archive, Azure Archive, and GCS Archive. StorageMAP’s Storage Optimizer targets archive-eligible cold data for relocation to archive tiers as the highest-impact cost reduction opportunity in cold data tiering simulations.

The global archive storage market is projected to reach $30 billion by 2027, driven by regulatory data retention mandates and the declining cost of cloud archive tiers. Organizations in regulated industries typically must retain records for 5 to 30 years — making archive economics critically important for long-term IT budget planning.

A pharmaceutical company uses StorageMAP to migrate 20 years of completed clinical trial data (3.5 PB) to a combination of on-premises Cloudian HyperStore (for EU data residency compliance) and AWS S3 Glacier Deep Archive (for non-EU data), achieving 97% total cost of ownership reduction versus continued primary NAS storage.

atime, or access time, is the file system timestamp that records the most recent moment at which a file’s content was opened for reading by any process. Its purpose is to provide an indicator of data access recency that complements mtime — capturing files that are read frequently but never modified, which would otherwise appear cold based on mtime alone. However, because recording an atime update on every file read generates significant write I/O overhead at scale, many NAS vendors and storage administrators disable atime updates or use approximate ‘relatime’ semantics. StorageMAP notes when atime is unavailable or unreliable in a source environment, as this materially affects the accuracy of read-frequency-based cold data classification.

Many NAS vendors and Linux distributions now default to relatime or noatime mount options to eliminate the write I/O overhead of per-read atime updates. Administrators relying on atime for cold data classification should explicitly verify that their NAS platform is maintaining atime before building tiering policies around it.

A storage architect validates atime reliability on a NetApp ONTAP volume by checking the ONTAP volume noatime option — if set to on, atime is not being updated and an mtime-only cold data policy must be used instead.

Azure Blob Storage is Microsoft Azure’s cloud object storage service, designed to store massive volumes of unstructured data — documents, images, video, backups, log files, and archives — at high durability and low cost through an HTTP-based REST API. Its purpose is to provide a scalable, serverless object store for cloud applications, analytics pipelines, backup and archiving, and content distribution, with multiple access tiers (Hot, Cool, Cold, Archive) for cost optimization based on access frequency. StorageMAP supports Azure Blob Storage as an object storage endpoint for O2O migrations, enabling data movement from S3-compatible sources to Azure using Blob’s S3-compatible interface or native API.

Azure Blob Storage is the second largest cloud object storage service globally. The Archive tier at $0.00099/GB/month makes it a cost-competitive choice for long-term compliance storage. Azure Blob supports immutable storage policies (WORM) via Blob Immutability Policies, meeting SEC 17a-4(f) compliance requirements.

A UK insurance company migrates 600 TB of historical claims records to Azure Blob Archive using StorageMAP, satisfying FCA record-keeping requirements at a storage cost 94% lower than their previous on-premises platform.

Azure Data Lake Storage Gen2 (ADLS Gen2) is a hierarchical namespace capability layered on top of Azure Blob Storage, adding true directory semantics, atomic directory operations, and POSIX-compatible ACLs to the existing object storage foundation to create a cloud storage tier optimized for large-scale analytics. Its purpose is to serve as the central storage layer for cloud analytics workloads running on Azure Synapse, Azure Databricks, and Azure HDInsight, where directory-level operations at petabyte scale are essential for pipeline performance. ADLS is relevant in StorageMAP contexts where NAS data is being migrated into a cloud analytics platform, as the hierarchical namespace bridges the gap between file system semantics and the object storage model.

ADLS Gen2 is the recommended storage backend for Azure Synapse Analytics, Azure Databricks, and Azure HDInsight, forming the foundational storage layer for modern cloud data lake architectures. It supports POSIX-style ACLs through the Azure Data Lake Storage REST API.

A financial services firm migrates 800 TB of historical trading data from an on-premises Isilon NAS to ADLS Gen2 using StorageMAP, enabling Azure Synapse Analytics to run regulatory compliance queries directly against the migrated data without requiring any ETL transformation.

Azure Files is a fully managed cloud file sharing service within Microsoft Azure that exposes shares over the SMB and NFS protocols, making it directly accessible to Windows and Linux clients using native operating system mount mechanisms without requiring any new client software. Its purpose is to provide a serverless, scalable replacement for on-premises Windows file servers and NFS NAS appliances, enabling organizations to lift-and-shift file workloads to the cloud without refactoring applications. Azure Files is a supported StorageMAP NAS migration target, with SMB protocol support and NTFS ACL preservation on Azure Files Premium tiers serving organizations migrating Windows file server workloads to Azure.

Azure Files Premium (SSD-backed) offers sub-millisecond latency with 100,000+ IOPS, making it suitable for business-critical SMB workloads previously only deployable on all-flash on-premises NAS.

A multinational retailer migrates their 300-branch Windows file server infrastructure to Azure Files using StorageMAP, reducing 300 physical file servers to a single globally managed Azure Files service — cutting storage management overhead by 85% and eliminating on-premises hardware refresh cycles.

Network bandwidth is the maximum sustained data transfer rate of a network connection, measured in megabits per second (Mbps) or gigabits per second (Gbps), representing the upper physical limit on how quickly data can be moved across any given network path. Its purpose as a metric is to characterize the available throughput capacity of a network link, which is the primary determinant of migration and replication job speed in StorageMAP operations. Bandwidth is a shared resource — multiple concurrent flows compete for capacity on any given link — and StorageMAP’s Throttling mechanism is used to limit the fraction of available bandwidth consumed by data operations, ensuring that migration traffic does not saturate production network links during business hours.

Industry context: Ethernet bandwidth has doubled approximately every 4 years over the past three decades — from 1 GbE in the late 1990s to 400 GbE today. Modern all-flash NAS systems can sustain I/O rates that saturate 100 GbE links, making high-speed Ethernet a prerequisite for achieving maximum migration throughput.

Example use case: a migration architect estimates migration duration using the formula: dataset_size_TB divided by effective_throughput_GB_per_second divided by 86400 seconds per day. A 400 TB dataset migrated at 700 MB/s (70% of 1 GbE link, throttled) completes in approximately 7 days.

Block storage is a data storage architecture in which data is divided into fixed-size chunks called blocks, each independently addressed by a numeric identifier and stored or retrieved without any knowledge of the file system or application context that governs its use. Its purpose is to provide a high-performance, low-latency storage substrate for applications that require precise, direct control over storage I/O — such as relational databases, virtual machine disk images, and high-frequency transaction systems — where block-level access patterns produce better performance than file or object abstractions. Block storage is managed at the SAN or locally attached disk level and is distinct from the file and object storage environments that StorageMAP directly scans and manages.

NVMe SSDs have reduced block storage latency from milliseconds (HDD SAN) to microseconds (NVMe-oF), enabling a new generation of in-memory-speed workloads. The global block storage market is estimated at $50+ billion annually.

During a data centre consolidation project, StorageMAP manages the NAS component — migrating 400 TB of file storage — while the block storage team uses vendor-native tools (NetApp SnapMirror, Dell EMC VPLEX) to handle the SAN component. The two workstreams are coordinated by the same project team but use separate tooling appropriate to each storage type.

A Bucket is the top-level container unit in an object storage system, within which all objects are stored under unique key names and against which access control, versioning, lifecycle, and logging policies are applied. Its purpose is to provide an isolated, addressable namespace for a collection of objects — analogous to a root volume or top-level share in a file system — that can be independently governed and accessed. In StorageMAP, Buckets are discovered when an object storage server is configured, selected as the scope of O2O migration and replication jobs, and represented in DQL scan results as the root container items in the storage hierarchy.

Industry context: the bucket model was pioneered by Amazon S3 in 2006 and has been adopted universally across cloud and on-premises object storage platforms. A bucket is analogous to a Windows share or Unix export in conceptual role but operates with a flat namespace and API-based access.

Example use case: a media company organises its object storage into buckets by project and year and uses StorageMAP to scan each bucket independently, enabling per-project capacity reporting and selective migration of completed projects to archive-class storage.

Capacity planning is the proactive process of analyzing current storage consumption, projecting future growth, and ensuring that sufficient storage capacity is procured and provisioned before it is needed. Its purpose is to prevent the operational and financial consequences of running out of storage — including application failures, backup failures, data loss risk, and emergency hardware procurement at premium cost — by giving administrators visibility into consumption trends and headroom well in advance. StorageMAP directly supports capacity planning through its analytics capabilities, which provide granular visibility into current consumption by server, directory, owner, and file type, and through the Storage Optimizer, which identifies the capacity and cost savings achievable through data tiering.

Gartner’s Infrastructure & Operations best practice framework recommends maintaining a minimum 20% free space on all storage systems and a 12-month capacity forecast updated quarterly. Organizations that fail to capacity plan proactively spend an estimated 3 to 5 times more on emergency storage procurement than those with structured capacity management programmes.

A StorageMAP quarterly capacity report for a hospital network shows that two NAS systems will exceed 85% utilization within 60 days based on current growth trends — triggering a procurement action 90 days ahead of the crisis point and identifying 340 TB of cold medical imaging data eligible for archiving.

Chain of Custody is a StorageMAP feature that generates an auditable, item-level record of data integrity for every file or object transferred during a migration, capturing checksums of both source and target data, transfer timestamps, and per-item verification status. Its purpose is to provide formal, tamper-evident evidence that data arrived at the target intact and unmodified, satisfying the audit and compliance requirements of regulated industries such as financial services, healthcare, and legal services. The Chain of Custody report is produced as a signed deliverable at the conclusion of a migration and can be presented to auditors, regulators, or clients as cryptographic proof of migration completeness and integrity.

Regulated industries including financial services (SEC, FCA), healthcare (HIPAA), and government (FedRAMP, NIST) increasingly require demonstrable evidence that data migration did not alter, corrupt, or lose records.

A legal discovery firm migrates 80 TB of case evidence files to a new WORM-compliant platform and uses the Chain of Custody report as courtroom-admissible evidence that every file arrived at the target with its content unchanged.

Chain of Custody aligns with NIST SP 800-88 guidelines for data integrity verification and SEC Rule 17a-4(f) requirements for broker-dealer record preservation.

A checksum or cryptographic digest is a fixed-length value computed from a data payload by passing it through a hash algorithm — such as MD5, SHA-256, or SHA-512 — that serves as a unique mathematical fingerprint of that specific content. Its purpose is to provide a verifiable proof of data integrity: any modification to the original data, however small, produces a completely different digest value, making it a reliable mechanism for detecting corruption or unauthorized alteration during storage, transfer, or transformation. StorageMAP computes and compares checksums during migration operations when Chain of Custody mode is enabled, generating cryptographically sound per-item evidence that every transferred file or object arrived at the target identical to its state on the source.

MD5 is fast but cryptographically broken for security purposes and should only be used for integrity checking. SHA-256 is the current standard for security-grade integrity verification.

A regulatory-grade Chain of Custody report produced by StorageMAP includes SHA-256 checksums for every file in a 15 TB legal evidence migration, providing a court-admissible integrity record that proves no file was modified between source and target — a standard requirement in e-discovery engagements governed by Federal Rules of Civil Procedure (FRCP) Rule 34.

A Classifier is a reusable StorageMAP configuration that categorizes scanned data into user-defined named groups based on one or more attribute conditions, such as file age, size, extension, or owner. Its purpose is to impose meaningful business structure on raw storage metadata — grouping files according to data temperature, retention class, ownership, or type — so that administrators can understand storage composition at a glance and build targeted datasets. Classifiers use AND/OR condition logic and support multiple condition groups; items that match no defined category are placed in a residual bucket to ensure complete coverage.

A storage architect creates a Data Temperature Classifier with four categories — Hot (accessed within 90 days), Warm (91 to 365 days), Cold (1 to 3 years), and Archive (over 3 years) — based on atime and mtime conditions. Applied to a 500 TB file server, the Classifier reveals that 62% of data qualifies as Archive, instantly quantifying the potential scope of a tiering project.

Data temperature classification is a foundational concept in Information Lifecycle Management (ILM) frameworks endorsed by SNIA and major storage vendors.

Cloudian HyperStore is an enterprise S3-compatible object storage platform available as purpose-built appliances and as software deployable on commodity servers, providing full AWS S3 API compatibility — including versioning, server-side encryption, bucket policies, and object tagging — in a private on-premises deployment. Its purpose is to enable organizations to build a self-managed, compliant private cloud object store that is fully interoperable with the S3 ecosystem of applications and tools, while keeping data within their own data center for sovereignty, latency, or regulatory compliance reasons. Cloudian HyperStore is a supported StorageMAP object storage endpoint, used as a source when migrating existing on-premises object data to cloud or a newer platform, and as a target when building a new on-premises S3 infrastructure.

Cloudian HyperStore has achieved SEC Rule 17a-4(f) WORM compliance certification, making it widely deployed in financial services organizations that need on-premises WORM-compliant object storage. HyperStore appliances can be deployed in as few as 3 nodes and scale to hundreds of petabytes.

A regional broker-dealer deploys Cloudian HyperStore as its SEC-compliant WORM archive and uses StorageMAP to migrate 120 TB of historical trade records from its legacy EMC Centera platform to HyperStore, preserving all retention lock attributes through StorageMAP’s WORM migration capability.

Cold Data is data that has not been accessed or modified within a user-defined period of time, indicating that it no longer justifies placement on high-performance, high-cost primary storage. Its significance in the context of storage management lies in the fact that cold data consumes expensive capacity without delivering corresponding business value, representing an immediately addressable opportunity for cost and carbon reduction. In the Storage Optimizer, cold data is identified based on configurable conditions applied to scan index results — such as files not accessed in 18 months — and the resulting classification drives both the cost savings simulation and the dataset used to target a Data Move action.

Analyst research consistently shows that 60 to 80% of data on enterprise primary storage has not been accessed in over a year.

A bank defines cold data as any file not accessed in 730 days and not tagged with a legal hold. Running this definition against its 3 PB file estate identifies 1.8 PB immediately eligible for archiving to object storage, reducing primary NAS refresh costs by an estimated $900,000.

Moving cold data to WORM-protected archive storage simultaneously satisfies SEC Rule 17a-4 retention requirements, turning a cost-saving exercise into a compliance improvement.

crtime, or creation time, is the file system timestamp that records the original date and time at which a file was first created. Its purpose is to provide an immutable birth date for the file, valuable in data lifecycle management, compliance retention tracking, and storage age analysis. crtime is natively available on Windows NTFS and on certain NAS platforms such as NetApp ONTAP, but is not a standard POSIX attribute and is not available on all Linux file systems or accessible over older NFS protocol versions. StorageMAP reports crtime in DQL scan output where the source platform exposes it, and returns NULL for items where the underlying file system does not maintain a creation timestamp.

An HR department needs to identify all files created during an employee’s tenure for a legal discovery request. Using crtime in a DQL HAVING clause — crtime after a specific start date and before a specific end date — instantly scopes the dataset to only files created during the relevant period.

crtime availability has improved in modern file systems — APFS (macOS), NTFS (Windows), and ext4 (Linux kernel 4.11 and later) all support creation time, but it remains unavailable in NFSv3 and must be explicitly supported at the NAS vendor level.

ctime, or change time, is a file system timestamp that records the most recent moment at which a file’s metadata — such as its permissions, owner, or link count — was modified, regardless of whether the file’s content was altered. Its purpose is to capture a broader class of file changes than mtime alone, enabling audit systems and cache invalidation mechanisms to detect any structural change to a file record, not just content writes. On Linux and NFS-based file systems, ctime is maintained automatically by the kernel and is distinct from mtime; its availability in StorageMAP scan results depends on the underlying NAS platform and protocol, and it is reported as NULL where the source does not expose it.

A security operations team uses ctime-based queries in DQL to identify files whose permissions were changed in the last 24 hours — a potential indicator of privilege escalation or ransomware activity. Because ctime captures permission changes that mtime does not, it is the correct timestamp for detecting security-relevant metadata modifications.

ctime is used by Unix backup utilities (rsync, tar) and security monitoring tools (Tripwire, AIDE) as a reliable indicator of file system change beyond content writes.

A Dashboard is a configurable analytics view in StorageMAP that assembles visual widgets representing key metrics about the monitored storage infrastructure, such as capacity usage trends, data age distributions, file type breakdowns, and tag-based summaries. Its purpose is to provide continuous, high-level visibility into the health and composition of an organization’s unstructured data estate without requiring active navigation. Dashboards are used by storage managers and executives to track consumption over time, identify risks, monitor progress against storage reduction targets, and communicate the business impact of data growth.

A monthly Storage Governance Review meeting is supported by a StorageMAP Dashboard projected for all attendees, showing year-over-year capacity growth by business unit, a rolling 12-month cold data trend, and current migration job progress. The Dashboard is configured once and auto-refreshes from live scan data at every subsequent meeting.

Automated, data-driven reporting replaces manual slide deck preparation, reducing the reporting burden while improving accuracy and currency of the information presented.

Data Access Governance (DAG) is the discipline of defining, enforcing, and continuously auditing who has access to which data, under what conditions, and for what purpose. Its purpose is to ensure that access rights across an organisation’s data estate are appropriate, least-privilege, and verifiable — reducing the risk of data breaches, insider threats, and compliance failures. StorageMAP surfaces the access control landscape of every scanned file and object, exposing POSIX permissions, ACLs, SID mappings, and share-level permissions, giving governance teams the visibility they need to identify and remediate over-permissioned data before migration or cloud transition.

Industry context: analyst firm KuppingerCole estimates that 30–40% of enterprise file shares contain data that is accessible to far more users than business need justifies. Regulatory frameworks including SOX, ISO 27001, and NIST SP 800-53 mandate periodic access reviews, and DAG tooling is increasingly required by cyber-insurance underwriters as a condition of coverage.

Example use case: a healthcare provider preparing for a NAS-to-NAS migration uses StorageMAP to enumerate all share and folder permissions on source filers, identifies 1.2 TB of patient records accessible to the entire domain, and triggers a remediation workflow to scope those permissions correctly before switchover, ensuring the migrated estate meets HIPAA minimum-necessary access requirements.

Benefit: by embedding DAG analysis into the migration workflow, StorageMAP ensures that access rights are validated and corrected at transition time rather than inherited as technical debt into the target environment — a far cheaper remediation point than post-migration audit.

Data at rest is information persisted to a storage medium — hard disk, solid-state drive, tape, or cloud object store — as opposed to data in active memory or in transit across a network. Its purpose as a security classification is to identify data that is potentially vulnerable to unauthorized access through physical or logical compromise of the storage media itself, making encryption at the storage layer the primary control for protecting it. Encryption of data at rest — typically AES-256, implemented via self-encrypting drives or storage-OS-level encryption — ensures that raw data read from media is unreadable without the encryption keys. StorageMAP deployments should ensure that both the Core server and all managed storage endpoints have encryption at rest enabled as a baseline security requirement.

Encryption at rest is now a baseline compliance requirement under GDPR, HIPAA, PCI-DSS, and FedRAMP. Many regulatory frameworks allow encrypted data to be treated as effectively anonymized for breach notification purposes, meaning that a storage system failure or physical theft does not constitute a reportable data breach if all-drive encryption is enabled.

Before executing a migration from an unencrypted legacy NAS to a new NetApp ONTAP system with NSE (NetApp Storage Encryption) enabled, the security team confirms that all data at rest will be AES-256 encrypted on the target — a security improvement that is an explicit objective of the migration project alongside the infrastructure refresh.

A Data Catalog is an organized inventory of an organisation’s data assets — files, objects, datasets, databases, and their associated metadata — that enables users to discover, understand, and govern data at scale. Its purpose is to make data findable and trustworthy by maintaining rich, searchable descriptions of what data exists, where it lives, who owns it, how sensitive it is, and how it may be used. In StorageMAP, the Discovery engine continuously scans connected storage systems and populates a live catalog of every file and object across the unstructured data estate, providing the foundational inventory on which classification, governance, and migration decisions are based.

Regulatory frameworks such as GDPR, CCPA, and HIPAA require organizations to know precisely what personal or sensitive data they hold and where it resides — obligations that are impossible to fulfill without a comprehensive data catalog. Gartner lists data cataloging as a core capability of the modern data management stack, and adoption has accelerated as enterprises consolidate petabyte-scale NAS and object storage environments into hybrid cloud architectures.

A financial services firm with 8 PB spread across twelve file servers uses StorageMAP’s discovery catalog to identify all files containing customer PII before initiating a cloud migration, ensuring that sensitive data is routed to appropriately governed storage tiers and that access controls are preserved throughout.

Treat the data catalog as a living system rather than a one-time audit. Schedule regular StorageMAP rescans so that the catalog reflects the current state of the estate, and integrate catalog metadata with downstream tools — SIEM, DLP, and ITSM platforms — to operationalize governance continuously.

A Data Copy is a StorageMAP action that duplicates a selected dataset from a source storage location to a target while leaving the original data fully intact on the source. Its purpose is to support scenarios that require a secondary copy of data without removing or modifying the primary — such as pre-migration staging, distributing a dataset to a new environment, or creating a point-in-time copy for compliance or audit purposes. Data Copy operations are configured against datasets produced by Analysis or Workflow steps and can be combined with scheduling to automate periodic copy cycles.

Before a major file server migration, a Data Copy job creates a full pre-migration snapshot of a 50 TB legal archive to a separate compliance NAS, providing an independent reference copy that can be used to demonstrate data integrity post-migration.

Data Copy enables risk-mitigation strategies such as copy-before-move, dual-write staging, and test environment provisioning that would otherwise require custom scripting or third-party tools.

A Data Deletion is a StorageMAP action that permanently removes a selected dataset from a storage system. Its purpose is to reclaim storage capacity and reduce operational costs by eliminating data that has been identified — through analysis and classification — as expired, redundant, or no longer required under the organization’s retention policies. Because deletion is irreversible, StorageMAP integrates the deletion action with the Approval Gate mechanism in Workflow configurations, ensuring that a responsible administrator reviews and authorizes the specific data in scope before any permanent removal is executed.

Data deletion is increasingly driven by regulatory requirements. GDPR Article 17 mandates the right to erasure, requiring organizations to delete personal data upon request.

A retail company runs a quarterly Workflow that identifies and deletes customer files whose retention period has expired, freeing 12 TB per quarter and ensuring GDPR compliance.

Always configure a mandatory Approval Gate before any Data Deletion job that targets more than 1 TB or 100,000 files, and retain the deletion audit log for at least 7 years.

Data in transit is information actively moving across a network connection between two endpoints — for example, between a client and a file server, between a Proxy and a storage system during a migration, or between an on-premises system and a cloud API endpoint. Its purpose as a security classification is to identify data that is exposed on the network and therefore potentially interceptable by parties with access to the network path between endpoints, making transport-layer encryption the essential control for protecting it. TLS (Transport Layer Security) is the standard encryption protocol for data in transit across HTTPS and S3 connections; SMB 3.x signing and encryption and NFSv4 with Kerberos provide protocol-level protection for file-sharing connections in StorageMAP environments.

PCI-DSS Requirement 4 mandates encryption of cardholder data in transit using strong cryptography (TLS 1.2 or higher). HIPAA Security Rule requires encryption or equivalent controls for PHI transmitted over open networks.

A healthcare organization migrating 200 TB of patient records enables SMB 3.x transport encryption for all migration traffic, ensuring that patient data is encrypted in transit between the source HNAS system and the target Azure Files Premium service — satisfying both HIPAA requirements and the organization’s internal security policy.

A Data Lake is a centralised storage repository that holds large volumes of raw, unprocessed data in its native format — structured, semi-structured, and unstructured — until it is needed for analysis, machine learning, or downstream processing. Its purpose is to provide a single, scalable, low-cost store for all enterprise data, decoupling storage from compute and enabling diverse analytical workloads to query the same underlying dataset without requiring upfront schema definition. Data lakes are typically built on object storage platforms such as Amazon S3, Azure Data Lake Storage, or Google Cloud Storage, and StorageMAP is commonly used to migrate on-premises NAS content into data lake architectures as part of cloud transformation programmes.

Industry context: data lakes emerged in the early 2010s as enterprises sought a cost-effective alternative to data warehouses for storing raw data at petabyte scale. While data lakes deliver flexibility and low storage cost, they are prone to becoming ‘data swamps’ without strong governance — making tools like StorageMAP’s data catalog and classification capabilities essential for maintaining data quality and discoverability.

Example use case: an energy company consolidates seismic survey data, sensor telemetry, and engineering documents from fourteen on-premises file servers into a centralised ADLS data lake using StorageMAP. The migration preserves all metadata and access controls, and StorageMAP’s post-migration catalog provides the data engineering team with a searchable inventory of all ingested assets.

Best practice: establish a data governance framework before populating a data lake — define ownership, classification, retention, and access policies for each data domain. Ungoverned data lakes rapidly accumulate redundant, obsolete, and trivial (ROT) data that inflates storage costs and degrades analytical value.

A Data Move is a StorageMAP action that transfers a selected dataset from its current storage location to a specified target and removes the data from the source once the transfer is confirmed successful. Its purpose is to implement data tiering, consolidation, or lifecycle management policies by physically relocating data to the storage tier or system most appropriate for its current business value — for example, moving files not accessed in three years from expensive primary NAS to low-cost cloud object storage. Data Move operations are configured against datasets produced by an Analysis or Workflow and preserve full metadata and permissions during the transfer.

After an analysis reveals 800 TB of files not accessed in three years on a premium NetApp AFF array costing $6.50/TB/month, a Data Move job relocates the eligible dataset to an on-premises MinIO S3 cluster at $0.35/TB/month — saving approximately $4.9M in annual storage costs with a one-time migration effort.

Data Move operationalizes the ILM (Information Lifecycle Management) principle that data should reside on the most cost-appropriate tier for its current value — a concept formalized by SNIA and incorporated into storage vendor product roadmaps as a standard enterprise requirement.

Data Security Posture Management (DSPM) is a category of security practice and tooling that continuously discovers where sensitive data lives, evaluates the security controls protecting it, identifies misconfigurations or excessive exposure, and provides prioritised remediation guidance. Its purpose is to give security teams a real-time, risk-ranked view of the organisation’s data security posture across hybrid and multi-cloud environments. StorageMAP contributes to a DSPM programme by providing deep visibility into unstructured data — the category most commonly overlooked by traditional DSPM tools — surfacing sensitive file locations, permission anomalies, and stale cold data exposure across NAS, object storage, and cloud storage.

Industry context: Gartner introduced DSPM as a distinct market category in 2022, driven by the proliferation of cloud data stores and the corresponding explosion in data exposure incidents. DSPM platforms are increasingly required by enterprise security architecture reviews, and unstructured file data — which represents over 80% of enterprise data volume — is the fastest-growing attack surface in scope.

Example use case: a global retailer integrates StorageMAP into its DSPM workflow to continuously scan 15 PB of NAS storage for files containing payment card data (PCI DSS scope). StorageMAP’s classifiers flag sensitive files, the data catalog records their locations, and the DAG layer identifies which are accessible beyond authorised groups — generating a prioritised risk report that feeds the security team’s remediation queue.

Standard alignment: DSPM programmes typically map to NIST CSF ‘Identify’ and ‘Protect’ functions, ISO/IEC 27001 Annex A controls for access management and information classification, and specific regulatory obligations under GDPR Article 32 (security of processing) and PCI DSS Requirement 3 (protect stored account data).

Data tiering is the practice of distributing data across multiple storage systems or storage classes with different performance, availability, and cost profiles — matching the expense of storing each item to its current business value and access frequency. Its purpose is to reduce the overall cost of the storage estate by ensuring that expensive high-performance capacity is used only for data that actively warrants it, while infrequently accessed data is systematically relocated to cheaper, less performant tiers without impacting the users and applications that need it. StorageMAP implements policy-driven data tiering through the combination of its Analytics module (to identify cold data), Storage Optimizer (to quantify the cost benefit), and Data Move actions (to execute the relocation).

SNIA defines Hierarchical Storage Management (HSM) as the foundational standard for automated data tiering, establishing the principle that data should flow automatically between tiers based on access patterns.

A global energy company implements a four-tier data management strategy using StorageMAP: active data on NetApp AFF (tier 1), warm data on NetApp FAS (tier 2), cold data on StorageGRID S3 (tier 3), and archive on AWS Glacier (tier 4). StorageMAP Workflows automate the quarterly movement of data between tiers based on access age, reducing annual storage costs by $3.8M across a 12 PB estate.

Datadobi Query Language (DQL) is a specialized declarative query language designed for interrogating the metadata indexes produced by StorageMAP scans and exporting the results to a structured SQLite3 database. Its purpose is to provide technical users — data engineers, storage architects, and compliance analysts — with a precise, programmable interface to the full depth of StorageMAP’s scan data, enabling queries and reports that go beyond what the graphical interface supports. DQL is used to produce custom inventory lists, automate compliance evidence exports, generate financial capacity reports, and feed external analytics pipelines with file system intelligence derived from StorageMAP scan results.

Example use case: a compliance analyst needs a monthly report of all files owned by contractors that are larger than 100 MB and have not been accessed in over 90 days. A DQL query produces this as a structured SQLite3 database in under 5 minutes, ready for import into their compliance reporting platform.

Industry alignment: DQL’s SQLite3 output format ensures compatibility with virtually any data analysis tool, including Python, R, PowerBI, Tableau, and custom ETL pipelines — making StorageMAP scan data accessible to data engineering teams without requiring specialist product training.

A Dataset is the output produced by running an Analysis in StorageMAP, representing a defined, named collection of files or objects that share a set of evaluated characteristics. Its purpose is to create a repeatable, actionable reference to a specific subset of storage data that can be tracked over time, reported on, or acted upon. Datasets are used as direct inputs to Data Copy, Data Move, and Data Deletion operations, and can be exported as CSV files for use in external reporting, compliance tracking, or capacity planning tools.

Example use case: a compliance team needs to verify that all files belonging to a departed employee have been accounted for. They run an Analysis filtered by owner UID, produce a Dataset, export it as CSV for legal review, and then use the same Dataset as the input for a Data Move action that archives the files to a WORM-compliant object store. This end-to-end workflow — from analysis to action — is completed without writing a single line of code.

Deduplication is a storage efficiency technology that identifies redundant copies of repeated data blocks across a storage system and replaces each duplicate block with a lightweight reference to a single retained copy, reducing the physical capacity required to store the logical data. Its purpose is to lower the effective cost per GB of storage for datasets with high content repetition — virtual machine images, backup repositories, user file shares, and email archives — by storing unique data only once regardless of how many times it appears. Deduplication savings are not automatically preserved during StorageMAP migrations, as data is transferred at the logical level; effective capacity on the target depends on whether the target platform independently deduplicates the incoming data.

Deduplication ratios vary dramatically by data type — virtual machine images and backup datasets typically achieve 10:1 to 50:1 ratios, while medical imaging, video, and already-compressed files achieve near 1:1.

A StorageMAP migration from a NetApp ONTAP source with 4:1 deduplication efficiency transfers 200 TB of logical data. The target AFF array achieves 3.5:1 deduplication on the same dataset, resulting in 57 TB of physical capacity consumption on the target — the capacity planning exercise uses logical sizes from StorageMAP scans to size the target volume.

Dell EMC Isilon, rebranded as Dell PowerScale, is a scale-out NAS platform powered by the OneFS clustered operating system that presents all cluster nodes as a single global namespace and scales from a few nodes to hundreds within a single file system. Its purpose is to provide a high-capacity, highly available NAS solution for organizations in media and entertainment, life sciences, financial services, and research that manage petabyte-scale unstructured data repositories requiring continuous, concurrent access from large numbers of clients. PowerScale is supported in StorageMAP as an integrated file server accessed via OneFS native APIs, making it one of the most commonly encountered platforms in large-scale NAS migration projects.

Dell PowerScale is the market-leading scale-out NAS platform, with over 50 petabytes of new PowerScale capacity shipped annually to customers in media, life sciences, and financial services. The OneFS platform’s single global namespace is its defining architectural advantage.

A major streaming media company uses StorageMAP to migrate 5 PB of completed content from an ageing Isilon Gen5 cluster to a new PowerScale F900 all-flash cluster, using StorageMAP’s incremental sync to run the migration over 8 weeks while the source continues to serve active production workflows.

Dell EMC PowerStore is Dell’s current-generation all-flash unified storage platform, providing both NAS (NFS and SMB) and SAN (iSCSI and Fibre Channel) workloads in a scale-out, appliance-based architecture with embedded machine learning for autonomous operations and workload optimization. Its purpose is to serve as a modern, high-performance storage consolidation platform for enterprise applications, virtualization, and unstructured data workloads, replacing aging Dell Unity, VNX, and legacy EMC systems. PowerStore is relevant in StorageMAP migration contexts as a high-performance NAS target for organizations consolidating onto current Dell infrastructure.

PowerStore introduced Dell’s container-based architecture, using NVMe drives with in-line storage service processing rather than traditional RAID controllers, enabling dynamic performance scaling without manual volume management.

A regional bank replaces its end-of-life Dell EMC Unity 450F with a PowerStore 3200T using StorageMAP to migrate 80 TB of Windows file server data over three weekends, maintaining full NTFS ACL integrity and achieving a final Switchover window of 8 minutes.

Dell EMC Unity is a mid-range unified storage array from Dell Technologies that supports NAS (NFS and SMB), SAN (iSCSI and Fibre Channel), and VMware-optimized workloads on a single platform, positioned as a cost-efficient storage system for mid-market and enterprise branch environments. Its purpose is to provide block and file services with integrated snapshot, replication, and thin provisioning capabilities at an accessible price point. Dell Unity systems are a frequently encountered source in StorageMAP NAS migration projects, particularly as organizations refresh end-of-life Unity deployments onto newer platforms such as PowerStore or cloud-based file services.

Dell EMC Unity was positioned as the successor to the VNX and VMAX ME platforms for midrange workloads and achieved widespread adoption between 2016 and 2022. With the introduction of PowerStore, Unity entered maintenance mode, making Unity-to-PowerStore migrations a major use case in Dell customer environments.

A higher education institution with 12 Dell EMC Unity arrays uses StorageMAP to consolidate all file workloads onto a single PowerStore 9200T, reducing storage management complexity and cutting annual maintenance costs by $280,000.

Dell Technologies is a global technology corporation and one of the world’s largest providers of enterprise IT infrastructure, formed through the 2016 merger of Dell and EMC. Its purpose in the storage market is to deliver a comprehensive portfolio of storage solutions — including all-flash unified storage (PowerStore), scale-out NAS (PowerScale), enterprise block (PowerMax), and object storage (ECS) — serving organizations from mid-market to hyperscale. Dell storage systems, particularly Dell EMC Isilon/PowerScale and Unity, are among the most frequently encountered source platforms in StorageMAP migration projects as organizations modernize aging infrastructure or move workloads to cloud environments.

Dell Technologies holds approximately 18% of the global external storage market (IDC, 2024). Following the Dell-EMC merger in 2016, Dell’s storage portfolio covers every segment from entry-level PowerVault to enterprise PowerMax block storage and PowerScale scale-out NAS.

A global manufacturer uses StorageMAP to consolidate 35 legacy Dell EMC Unity and VNX NAS systems onto a new PowerScale cluster, completing a 7-year storage refresh programme that reduces 35 management interfaces to one.

Discovery is a module within StorageMAP ASP Migrate Edition that scans file servers to produce a structured planning report ahead of a migration project. Its purpose is to dimension the source file system, surface potential incompatibilities, and provide the quantitative data needed to scope and sequence migration work before any data movement begins. Discovery is used in the early stages of a migration engagement to gather statistics on share counts, file counts, total capacity, depth of directory trees, file age distributions, and protocol configurations — all of which feed directly into the migration plan and help identify risks or preparation steps required before the migration can proceed.

Before scoping a 200 TB Isilon migration for a media client, a service provider runs Discovery to find that the source has 47 shares — 12 of which are empty — 3.2 billion files, and a maximum directory depth of 512 levels. This reveals that the project requires a 60-day migration window rather than the initially estimated 30 days, preventing a costly contractual scope change later in the project.

Pre-migration Discovery aligns with ITIL Change Management best practices by ensuring that scope, risk, and resource requirements are fully understood before work commences.

Microsoft Distributed File System (DFS) is a Windows Server technology that provides a unified, location-transparent namespace for file shares distributed across multiple physical file servers, presenting them to clients as a single logical directory tree accessed through a stable UNC path regardless of where the underlying data physically resides. Its purpose is to abstract the physical topology of file server infrastructure from clients, enabling administrators to move, replicate, or rebalance data across file servers without changing the access paths that users and applications have configured. DFS is significant in StorageMAP NAS migration projects because DFS namespace entries must be updated to point to the new target server at the point of Switchover, and DFS referrals are recognized and flagged as special item types during StorageMAP scans.

Microsoft DFS was introduced with Windows Server 2003 R2 and is widely deployed in enterprise Windows environments for branch office file sharing, where DFS Replication (DFSR) keeps local copies synchronized across sites. DFS Namespace is now the standard method for abstracting Windows file server access paths in enterprise environments.

A global enterprise with 80 branch offices uses StorageMAP to migrate the underlying file server data to a new target, then updates the single DFS namespace target link at Switchover — redirecting all 80 branch offices simultaneously with a single change rather than 80 individual mount point updates.

The Domain Name System (DNS) is the hierarchical distributed naming system that translates human-readable hostnames and fully qualified domain names into IP addresses and vice versa, operating over TCP and UDP on port 53. Its purpose is to provide the universal name resolution service upon which virtually every networked application — including file servers, object storage endpoints, identity providers, and management consoles — depends for connectivity by name rather than by IP address. In StorageMAP deployments, DNS is required for all component-to-component connectivity and for Proxy-to-storage-system access; at the Switchover phase of a migration, DNS record updates are the primary mechanism for redirecting client traffic from the decommissioned source to the new target without requiring individual client reconfiguration.

DNS was designed in 1983 (RFC 882/883) and is the most critical single piece of network infrastructure in any organization — more outages are caused by DNS misconfigurations than by any other network component. Reducing DNS TTL values to 60 seconds 24 hours before a migration Switchover ensures that DNS record updates for the new target server propagate to all clients within 1 minute of the change.

A StorageMAP migration switchover plan includes specific DNS update steps: pre-switch TTL reduction to 60 seconds, post-switch record update to point to target IP, and a 5-minute validation window confirming client connectivity to the new server.

A Dry Run is a test execution of a StorageMAP migration or workflow that simulates all configuration evaluation, planning, and validation steps without making any permanent changes to source or target systems. Its purpose is to identify configuration errors, connectivity issues, identity mapping problems, and scope discrepancies before the live migration is committed, reducing the risk of failures or surprises during the actual migration window. Dry Runs are used by migration architects during the planning and testing phase to validate that all components are correctly configured and to generate scope estimates for the live run.

A dry run of a 200-share SMB migration reveals that 14 shares have path lengths exceeding 260 characters — the Windows MAX_PATH limit — which would cause silent failures on the target. Addressing this before the live run prevents a post-migration incident.

Always run at minimum one dry run 48 to 72 hours before the live migration and review the report with the project team to action any identified issues.

Dry runs are the storage migration equivalent of pre-production environment testing in software delivery.

An Embedding is the process — or the output of that process — by which a machine learning model transforms raw data (text, images, audio, or structured records) into a dense numerical vector representation that captures the semantic relationships within the data. Its purpose is to map high-dimensional, heterogeneous data into a compact, comparable numerical space so that AI models can perform similarity search, clustering, classification, and retrieval operations efficiently. Generating embeddings from enterprise file content — documents, images, logs — requires first identifying and extracting that content from storage systems, a task for which StorageMAP’s discovery and classification capabilities provide the necessary data pipeline foundation.

Embedding models such as OpenAI’s text-embedding-ada-002, Cohere’s Embed, and open-source alternatives from Hugging Face are now standard components of enterprise AI stacks. The cost and latency of generating embeddings at scale — and the storage requirements of the resulting vector databases — are significant operational considerations as organizations move from prototype to production AI deployments.

A pharmaceutical company uses StorageMAP to discover and export all research reports from five years of NAS storage. The exported files are passed through a text embedding pipeline, and the resulting vectors enable researchers to find semantically similar studies across the entire corpus — surfacing connections that keyword search would have missed.

Align embedding model selection with the domain and language of the data being encoded. General-purpose embedding models perform well on broad corpora, but domain-specific models (trained on legal, medical, or financial text) typically produce more accurate similarity rankings for specialist content.

An ETag, or entity tag, is a unique value associated with an object in object storage that serves as a content fingerprint — typically computed as the MD5 hash of the object’s data — and is returned by the storage system as part of the object’s metadata on every request. Its purpose is to provide a lightweight integrity check that allows any consumer of the object to verify whether its content has changed since it was last retrieved, without downloading the full object, by comparing the current ETag against a previously recorded value. StorageMAP uses ETags during O2O migrations to verify per-object transfer integrity, preserving source ETags on target objects so that post-migration validation checks can confirm bit-for-bit data fidelity at the object level.

The ETag mechanism is defined in RFC 7232 (HTTP Conditional Requests) and is implemented consistently across all S3-compatible platforms. For objects uploaded as a single PUT, the ETag is always the MD5 of the object content.

After a 2 PB O2O migration from on-premises StorageGRID to AWS S3, a post-migration DQL query compares source and target ETags for 1.8 million objects, confirming that 100% of objects arrived with identical ETags — providing a cryptographically sound migration integrity certificate without requiring full content re-read.

The Explorer is an analytics view within StorageMAP that presents a real-time, navigable tree of all registered Scan Roots alongside live metrics for each node — including item counts, capacity figures, and current scan status. Its purpose is to give administrators immediate, visual orientation within the storage landscape without requiring a formal Analysis workflow. It is used as the primary entry point for ad-hoc navigation of scanned storage, allowing operators to drill down into any directory or bucket to review data volumes and status before deciding where to focus an investigation or action.

A newly onboarded storage engineer uses the Explorer on their first day to navigate all registered Scan Roots and immediately understand the top-level capacity distribution across the organization’s NAS estate — without needing any briefing from a colleague.

The Explorer’s live capacity tree eliminates the need for manual capacity spreadsheets, which are often out of date within days of being produced and require scripting expertise to generate.

The EXPORT statement is the primary structural clause of a DQL query, defining the name of the output table in the SQLite3 results database and the set of columns to be included in that table, each defined by an expression evaluated against each scanned item. Its purpose is to give the query author complete control over the shape, content, and naming of the output, producing a precisely structured data export tailored to downstream consumption. Each column in an EXPORT statement is defined by a DQL field expression, optionally aliased using the AS keyword, and the statement is paired with optional HAVING and ORDER clauses to filter and sequence the result rows.

A DQL query using EXPORT produces a table named cold_files_report with columns for path, size_gb, last_access_days, owner, and extension — exactly the columns needed for a management report. By defining the output schema explicitly, the analyst ensures that the downstream report template works identically every time the query is re-run against updated scan data.

Use meaningful table names and column aliases that describe the business intent of the query to make DQL queries self-documenting for other team members.

Extended attributes (xattr) are optional, application-defined name-value pairs stored by the file system in association with a file or directory, supplementing the standard fixed metadata fields with arbitrary, application-specific information. Their purpose is to allow applications, security systems, and management tools to attach custom structured data directly to files without modifying file content or encoding information in file names — common uses include SELinux security labels, macOS resource forks, content classification markers, and application workflow state. In StorageMAP, extended attributes — referred to as named streams or named attributes in NFSv4 contexts — can be configured for preservation during NFS migrations on platforms that expose them through the protocol.

Extended attributes are used by a growing range of enterprise applications — macOS uses them for Finder metadata, SELinux for security labels, and many DAM systems for workflow state. Failure to preserve xattr during migration can cause application failures on the target.

A media production company migrates a 200 TB content repository from an ageing NAS to a new Dell PowerScale system. StorageMAP is configured to copy all NFSv4 named attributes, ensuring that proprietary xattr-based workflow tags set by their Avid MediaCentral system are preserved and that the editorial team can resume work immediately after Switchover without re-tagging 2 million assets.

A Failback is the process of returning production workloads from the secondary system back to the primary after the primary has been repaired, rebuilt, or confirmed healthy following a Failover event. Its purpose is to restore the environment to its standard operating topology — with the primary serving live data and the secondary resuming its standby role — after the cause of the original failover has been addressed. StorageMAP manages the Failback workflow by first reverse-replicating any data written exclusively to the secondary during the failover period back to the primary, verifying synchronization, and then reconfiguring the replication job to resume its original primary-to-secondary direction.

After a planned Failover during a primary NAS hardware upgrade, StorageMAP executes a Failback by reverse-replicating the 8 GB of data written to the secondary during the maintenance period back to the primary in under 2 minutes, before restoring the standard primary-to-secondary replication direction. The entire process is completed within the scheduled 4-hour maintenance window.

Never perform a Failback under time pressure — take the time to fully validate the primary before switching, as a failed Failback may require another Failover.

A Failover is the operation that redirects active workloads and client connections from a primary storage system to its secondary (replicated) counterpart when the primary is unavailable or is being taken offline for planned maintenance. Its purpose is to restore data accessibility and application continuity with the minimum possible disruption and data loss, fulfilling the recovery objectives defined in the organization’s business continuity plan. StorageMAP supports both planned failovers — which use a maintenance window to drive the Recovery Point Actual to zero before switching — and unplanned failovers, which activate immediately upon primary system failure, accepting the data gap that existed at the moment of failure.

ITIL defines Recovery Time Objective (RTO) as the maximum acceptable time to restore service after an incident, and a Failover’s execution speed directly determines whether the RTO is met.

A hospital’s medical imaging NAS fails unexpectedly at 2 AM. The on-call engineer initiates a StorageMAP unplanned Failover within 3 minutes, activating the secondary and restoring radiologist access before the morning shift begins — meeting the 15-minute RTO defined in the hospital’s BC/DR plan.

Test Failover procedures at least annually in a planned drill to verify that RTO and RPO commitments are achievable in practice.

Fibre Channel (FC) is a high-speed, deterministic, lossless storage networking technology designed exclusively for connecting servers to block storage arrays in SAN environments, delivering throughput of 8, 16, 32, or 64 Gbps with extremely low and predictable latency through a dedicated, switched fabric of FC ports and FC switches. Its purpose is to serve as the preferred transport for the most demanding block storage workloads — mission-critical databases, mainframe storage, and high-frequency trading platforms — where deterministic sub-millisecond latency is a firm requirement. Fibre Channel is distinct from the file and object storage protocols that StorageMAP manages, but is relevant context for understanding the physical storage architecture underlying NAS systems in the data centers where StorageMAP is deployed.

Fibre Channel was standardized by ANSI in 1994 and has been the dominant enterprise SAN protocol for mission-critical block storage for 30 years. Gen 7 FC (64 Gbps, introduced 2019) is the current standard. FC fabrics require specialist FC switches (Brocade, Cisco MDS) and HBAs, creating a separate, dedicated SAN infrastructure managed independently of Ethernet networking.

A data centre consolidation project team uses StorageMAP for all NAS migrations while the SAN team uses host-based migration tools for the FC LUN migrations — the two teams coordinate on Switchover windows but operate their respective migration tools independently.

File metadata is the collection of descriptive attributes maintained by a file system about each stored file and directory, entirely separate from the file’s actual content. Its purpose is to enable the operating system, applications, and data management tools to identify, locate, secure, and manage files without reading their content — making it the foundational information layer for all storage governance operations. File metadata encompasses the file name, full path, logical size, size on disk, creation time, last modification time, last access time, owning user identity, owning group identity, permission bits or ACL entries, and extended attributes. StorageMAP collects and indexes file metadata during scans, uses it as the basis for all analytics and classification operations, and preserves it faithfully during migrations and replications.

POSIX defines a standard set of file metadata attributes (stat structure) that is implemented consistently across Unix/Linux file systems and NFS, forming the basis for interoperability between systems from different vendors.

StorageMAP’s file metadata index is the foundation for every governance capability — a 10 PB file system containing 5 billion files can be fully analyzed, classified, and reported on entirely from metadata, without reading a single byte of file content, in a matter of hours.

A file name is the human-readable identifier assigned to a file within its parent directory, forming the leaf component of the file’s full path and serving as the primary label by which both users and the operating system reference and distinguish files from one another. Its purpose is to provide a meaningful, navigable label for each stored item, enabling the file system to present a comprehensible hierarchy to users and applications. File naming rules vary by file system — NTFS is case-insensitive but case-preserving while most Linux file systems are case-sensitive — and name-based attributes such as file extension are commonly used as classifier conditions in StorageMAP analytics to categorize data by type.

File name conventions are a foundational element of information management practice. ISO 15489 (Records Management) recommends structured file naming policies as a prerequisite for effective records retrieval and lifecycle management.

A StorageMAP Classifier uses file extension as a condition — grouping .pst (Outlook archives), .vmdk (VM images), .mp4 (video), and .pdf (documents) — to produce an instant breakdown of the composition of a 400 TB file server. This extension-based classification is only possible because StorageMAP parses and indexes the file name for every scanned item.

A file path is the complete, unambiguous hierarchical address of a file within a file system namespace, expressed as a sequence of directory names separated by path delimiter characters from the root to the file name. Its purpose is to provide a globally unique identifier for any specific file within its storage environment, enabling tools, applications, and management systems to locate and operate on individual files without ambiguity across file systems containing billions of items. In StorageMAP’s DQL interface, the path field uniquely identifies every scanned item and is the primary field used to verify scope correctness, cross-reference migration source and target items, and construct compliance inventory reports.

A compliance team needs to verify that all files containing personal data are stored under approved directory paths. A DQL query filtering on path prefix instantly identifies 4,200 files outside the approved structure, enabling the data protection officer to initiate remediation.

Use path-based filtering as the first step in any compliance scoping exercise, as it narrows the in-scope dataset to known locations before applying more computationally intensive metadata-based classification.

A File Server in StorageMAP is a network-attached storage system registered as a managed endpoint in the platform’s configuration, serving as a source or target for scanning, migration, replication, or data action operations. Its purpose is to represent a storage system with defined protocol capabilities, network addresses, authentication credentials, and management interface details that StorageMAP uses to connect, traverse, and operate on the file system hosted by that system. File Servers can be integrated (using vendor-specific APIs for ONTAP or OneFS) or generic NAS (accessed purely over SMB or NFS), with integrated systems enabling richer operations such as automated share and export creation.

NAS file servers are the dominant form of shared storage in enterprise environments, with leading vendors including NetApp, Dell EMC, Hitachi Vantara, IBM, and cloud providers (AWS EFS, Azure Files).

A healthcare organization registers 23 file servers across three hospital campuses in StorageMAP — a mix of NetApp FAS, Dell EMC Unity, and Azure Files instances — and manages their full data lifecycle from a single StorageMAP Core instance.

Registering all storage endpoints in StorageMAP provides a single pane of glass that eliminates the need to manage each vendor’s native management UI separately for data governance purposes.

A File System Assessment (FSA) is a licensed analytics capability within StorageMAP ASP Migrate Edition that enables detailed pre-migration scanning, results review, and structured report generation. Its purpose is to produce a formal, documented assessment of a source file system’s structure, composition, and migration readiness, suitable for delivery to clients or internal stakeholders. FSA is used during the discovery and planning phase of a migration engagement; results can be exported as CSV or PowerPoint artifacts for project planning, scope documentation, and stakeholder sign-off. The FSA capability is activated by uploading an FSA flag license to the StorageMAP instance.

A managed service provider delivers an FSA PowerPoint to a prospective client showing that their 800 TB file estate contains 340 TB of data not accessed in three years, costing an estimated $180,000 per year in unnecessary primary storage. The report becomes the commercial justification for a cloud migration engagement.

FSA transforms StorageMAP from an operational tool into a pre-sales and project initiation asset, enabling data-driven conversations with clients about migration scope and ROI before any contract is signed.

A Filter is a rule set in StorageMAP that restricts the scope of an Analysis by evaluating each scanned item against one or more conditions and including only those that satisfy the rule. Its purpose is to reduce large, heterogeneous storage datasets to the specific subset relevant to a given analysis goal, making it practical to work analytically across file systems containing hundreds of millions of items. Filters support ‘match all’ (AND) and ‘match any’ (OR) logic and are typically applied before or alongside Classifiers to progressively refine data toward a targeted, actionable dataset.

Before analyzing a home directory share, an administrator applies a Filter that excludes files smaller than 1 MB and items modified in the last 30 days, immediately reducing the working set from 50 million items to 800,000 items — making the subsequent Classifier run orders of magnitude faster.

Always apply the most selective filters first to minimize the dataset before adding classification steps, particularly in scan roots containing tens of millions of items.

A firewall is a network security system — implemented in hardware, software, or both — that inspects and controls network traffic based on a defined rule set, permitting or blocking connections based on source and destination addresses, port numbers, protocols, and connection state. Its purpose is to enforce network access control policies, protect storage and management systems from unauthorized access, and segment network traffic between security zones. In StorageMAP deployments, firewall rules must explicitly permit all required protocol traffic — including SMB on TCP 445, NFSv4 on TCP 2049, S3/HTTPS on TCP 443, LDAP on TCP 389, and StorageMAP web/API traffic on HTTPS — between each pair of components that need to communicate, and incorrect or missing rules are among the most common causes of StorageMAP connectivity failures.

Industry context: next-generation firewalls (NGFWs) from vendors including Palo Alto, Fortinet, and Cisco perform deep packet inspection at line rate, potentially impacting storage protocol performance if storage traffic is subjected to DPI.

Best practice: configure firewall rules for storage protocol traffic to use stateful connection tracking without DPI to avoid introducing artificial latency.

Example use case: a StorageMAP deployment troubleshooting guide identifies firewall as the first item to check when migration throughput is unexpectedly low — a missing rule permitting SMB traffic on TCP 445 causes 0 MB/s transfer rate, immediately identifiable from StorageMAP job logs.

Generative AI (GenAI) is a class of artificial intelligence models capable of producing new content — text, images, code, audio, video, or synthetic data — that resembles the patterns of the data on which they were trained. Its purpose is to augment human productivity by automating the creation of content, accelerating knowledge work, and enabling new forms of human-computer interaction. The most commercially significant GenAI systems are large language models and multimodal models, and their application to enterprise unstructured data — generating summaries, answering questions, drafting documents — creates new requirements for how organisations discover, govern, and manage their underlying data estates.

Gartner predicts that by 2026, more than 80% of enterprises will have used GenAI APIs or models in production, up from under 5% in 2023. The primary bottleneck for enterprise GenAI deployment is not model capability but data readiness — organizations cannot safely apply GenAI to their data without first understanding what data they have, where it is, and who has access to it, making StorageMAP’s discovery and governance capabilities a GenAI enabler.

A manufacturing company deploys a GenAI-powered document assistant that answers engineer queries by retrieving relevant technical manuals and specifications from the company’s NAS estate. StorageMAP first discovers and classifies all documentation files, the embedding pipeline generates vectors for each document, and the RAG layer grounds the GenAI model’s responses in verified source material rather than hallucinated content.

Govern the data that feeds GenAI systems with the same rigour applied to regulated reporting data. Uncontrolled access to confidential or sensitive files by GenAI models — particularly through RAG pipelines — can inadvertently expose restricted information to users who would not have direct access to the underlying documents.

Global Settings are instance-level configuration options in StorageMAP that define platform-wide operational behaviors applying uniformly to all jobs, modules, and users within the deployment. Their purpose is to establish system-level governance controls and operational defaults — such as session timeout duration, minimum password age, LDAP/AD integration parameters, backup schedule for the StorageMAP database, and early access feature toggles — that ensure consistent, secure platform behavior across the entire instance. Changes to Global Settings are restricted to StorageMAP administrators and take effect immediately across all active sessions and jobs.

Review and document Global Settings as part of every StorageMAP deployment procedure, including session timeout (recommended 30 minutes for high-security environments), LDAP integration details, and backup schedule (recommended daily with 30-day retention).

Centralized, documented configuration management aligns with ITIL Configuration Management Database best practices and is required by ISO 27001 Annex A.12.1 (operational procedures and responsibilities).

Google Cloud Storage (GCS) is Google Cloud’s object storage service, providing durable, globally accessible storage for objects of any size through both a native JSON/REST API and an S3-compatible XML API, organized in buckets with multiple storage classes — Standard, Nearline, Coldline, and Archive — for cost optimization. Its purpose is to serve as the foundational storage layer for applications, data analytics pipelines, backup, archiving, and media processing workloads on Google Cloud Platform. StorageMAP supports GCS as an object storage endpoint for O2O migrations via the S3-compatible API, enabling organizations to move data from on-premises or other cloud object stores to Google Cloud as part of a broader cloud adoption or multi-cloud strategy.

GCS holds approximately 10% of the global cloud storage market and is the dominant choice for AI/ML workloads on Google Cloud Platform due to its deep integration with BigQuery, Vertex AI, and Dataflow. GCS Nearline ($0.01/GB/month) and Coldline ($0.004/GB/month) provide cost-effective tiers for infrequently accessed data.

A technology company running its ML pipeline on Google Cloud uses StorageMAP to migrate 2 PB of training datasets from an on-premises NetApp NAS to GCS Standard, enabling Vertex AI to access the datasets directly from GCS at cloud-native throughput speeds.

A hard link is a directory entry that maps a file name directly to the same inode — and therefore the same physical data on disk — as one or more other directory entries, creating multiple names for a single file without duplicating its content. Its purpose is to allow a file to be accessible from multiple locations in the directory tree simultaneously and to enable space-efficient file management patterns where applications need multiple references to the same data. Hard links have no equivalent in object storage. During StorageMAP migrations, hard-linked files require specific handling logic to avoid inadvertently creating independent copies of linked files on the target, which would inflate capacity consumption relative to the source.

Hard links are commonly used by Unix backup utilities — rsync uses them to create space-efficient incremental backup trees where unchanged files share inodes with previous versions. If a migration tool is unaware of hard links and copies each directory entry as a separate file, the target will consume significantly more space than the source.

A backup storage administrator migrates a 200 TB rsync backup repository to a new NAS. StorageMAP correctly identifies and handles hard-linked files, resulting in a target that consumes 198 TB — compared to a naive migration that would have produced 1.4 PB by copying each hard-linked file independently.

The HAVING clause is a DQL filtering construct that contains a Boolean expression evaluated against each scanned item to determine whether that item is included in the query output, serving the same logical role as a WHERE clause in standard SQL. Its purpose is to scope DQL query results to the specific subset of scanned data relevant to the query’s intent — for example, all files larger than 10 GB, all items not modified in more than 1,000 days, or all objects with a specific user-defined metadata key. HAVING conditions support the full range of DQL operators, field references, and expressions, and can combine multiple conditions using AND and OR logic.

A HAVING condition filtering for files larger than 1 GB and not modified in over 3 years applied to a 10 PB scan immediately narrows the result set from 2 billion items to 140,000 items — a 14,000-fold reduction that makes subsequent analysis and reporting fast and tractable.

Combine HAVING clauses with itemIsContainer = false to ensure that only leaf data items are included in capacity aggregations, preventing directories from inflating item counts and size totals.

The Hitachi NAS Platform (HNAS) is Hitachi Vantara’s enterprise NAS system, providing high-availability file storage over NFS and SMB protocols in a clustered architecture where multiple NAS heads share a common file system namespace and storage pool backed by Hitachi VSP block storage. Its purpose is to deliver reliable, high-performance file services for regulated industries — including financial services and healthcare — where data integrity, availability, and auditability are non-negotiable requirements. HNAS is a commonly encountered source platform in StorageMAP NAS migration projects for organizations refreshing aging Hitachi file storage infrastructure or consolidating onto modern NAS or cloud platforms.

HNAS is deployed at scale in financial services and healthcare environments where its integration with Hitachi’s enterprise-grade VSP backend provides additional data protection assurance. HNAS’s support for both NFS and SMB on the same namespace makes it common in mixed-protocol environments.

A global investment bank replaces its 8-node HNAS server farm with a NetApp AFF cluster using StorageMAP to migrate 1.2 PB over 12 weeks, with Chain of Custody enabled to provide auditable proof of data integrity for the bank’s internal audit committee.

Hitachi Vantara is the data infrastructure and analytics subsidiary of Hitachi, Ltd., providing enterprise storage and data management solutions with a focus on the highest reliability and data integrity for mission-critical deployments. Its storage portfolio includes the Virtual Storage Platform (VSP) for block storage and the Hitachi NAS Platform (HNAS) for file storage, both widely deployed in financial services, healthcare, manufacturing, and telecommunications sectors. Hitachi storage systems are encountered as source platforms in StorageMAP migration projects, particularly in Japanese corporations and global organizations with legacy Hitachi NAS infrastructure that is being modernized or consolidated.

Hitachi Vantara’s storage business has its strongest presence in Japan and Asia-Pacific, where Hitachi group companies are major customers. The VSP platform has achieved the highest availability ratings in independent benchmarks, with published availability figures of 99.9999% (six nines) over multi-year periods.

A Japanese bank migrates 400 TB from a Hitachi HNAS system to a new NetApp ONTAP platform using StorageMAP, managing the migration in parallel with an Active Directory domain consolidation that requires SID mapping for all 1.2 million ACL entries.

The Hitachi Virtual Storage Platform (VSP) is Hitachi Vantara’s flagship enterprise block storage array, recognized for industry-leading availability and designed for the most demanding SAN workloads in financial services, telecommunications, and large enterprise environments. Its purpose is to provide mission-critical block storage with extreme reliability — including non-disruptive upgrades, active-active controller configurations, and multi-petabyte scalability — for databases, ERP systems, and virtualization infrastructure. VSP is relevant in StorageMAP environments as the physical storage backend for HNAS NAS clusters, and understanding VSP’s underlying storage configuration is important for capacity planning in migrations involving HNAS source systems.

Hitachi VSP’s active-active cross-site replication (Global-Active Device) provides zero-RPO, zero-RTO block-level replication across two data centres, making it the preferred platform for mission-critical trading and core banking applications. VSP systems are designed for 15+ year operational lifespans.

A regional bank migrating from a VSP-backed HNAS NAS to a new NetApp ONTAP system uses StorageMAP for the NAS data migration while the VSP remains in service for SAN workloads, allowing the two migration workstreams to proceed independently.

Hot data is data that is accessed frequently — typically multiple times per day or week — and whose I/O latency and throughput characteristics directly impact the productivity of users or the performance of applications that depend on it. Its purpose as a category is to identify the active, business-critical portion of the storage estate that justifies placement on high-performance, high-cost primary storage such as all-flash NAS or premium cloud object storage tiers. In StorageMAP’s Storage Optimizer, hot data is implicitly the inverse of cold data — everything not meeting the cold data conditions — and the value of the optimizer is in quantifying how large the cold fraction is and what it costs to keep it on hot-tier infrastructure.

Research consistently shows that less than 20% of data on primary storage is actively hot — accessed within the past 90 days. Yet 100% of primary storage capacity is priced and provisioned as if all data is hot, making hot/cold stratification the primary economic efficiency opportunity in unstructured data management.

A StorageMAP analysis of a 2 PB investment bank NAS estate reveals that only 320 TB (16%) was accessed in the last 90 days. The remaining 1.68 PB is cold and immediately eligible for tiering — a finding that generates a $2.4M annual savings opportunity when modelled in the Storage Optimizer.

IBM (International Business Machines) is a global technology company with a significant enterprise storage portfolio spanning high-performance parallel file systems (Spectrum Scale/GPFS), all-flash unified storage (FlashSystem), and cloud object storage (IBM Cloud Object Storage). Its purpose in the storage market is to provide reliable, high-performance storage infrastructure for mission-critical enterprise workloads in sectors such as financial services, healthcare, manufacturing, and government. IBM storage systems are encountered in StorageMAP migration environments as source platforms when organizations are modernizing away from legacy IBM storage infrastructure or transitioning workloads to modern NAS or cloud platforms.

IBM’s enterprise storage business has focused increasingly on all-flash arrays and hybrid cloud solutions, with IBM FlashSystem consistently ranked among the top enterprise block storage platforms by Gartner. IBM’s GPFS technology remains the dominant parallel file system for HPC environments globally.

A national laboratory migrates 800 TB of completed research data from IBM Spectrum Scale to a NetApp ONTAP NAS using StorageMAP, freeing Spectrum Scale capacity for active HPC workloads while enabling research data to be accessed by non-HPC users through standard NFS mounts.

IBM Cloud Object Storage is IBM’s S3-compatible object storage service, available as a managed service on IBM Cloud and as an on-premises appliance system derived from Cleversafe’s dispersed storage technology, which distributes erasure-coded data fragments across multiple sites for maximum geographic resilience. Its purpose is to provide a highly durable, geographically distributed object store for backup, archiving, analytics, and content delivery workloads, within IBM Cloud and in enterprise on-premises environments where data sovereignty or latency requirements preclude public cloud storage. IBM Cloud Object Storage is a supported object storage endpoint in StorageMAP, used as either a source or target in O2O migration workflows.

IBM Cloud Object Storage uses Cleversafe’s patented dispersed storage technology, which divides objects into slices distributed across multiple sites — providing geo-redundancy without traditional replication overhead. This architecture can tolerate the complete loss of multiple sites simultaneously without data loss.

A financial trading firm migrates 2 PB of historical market data from on-premises tape to IBM Cloud Object Storage using StorageMAP, reducing retrieval time from 4 to 8 hours (tape) to seconds while simultaneously satisfying FINRA 7-year retention requirements.

IBM FlashSystem is IBM’s enterprise all-flash storage array product line, running IBM Spectrum Virtualize software to deliver high-performance block and unified storage with advanced features including thin provisioning, snapshots, replication, storage virtualization, and the ability to manage external third-party storage volumes behind a FlashSystem controller. Its purpose is to provide the high IOPS, low latency, and enterprise reliability required for mission-critical applications such as databases, ERP systems, and virtual machine environments. FlashSystem supports both SAN (iSCSI, FC, NVMe-oF) and NAS (NFS, SMB) protocols, making it relevant as a unified migration target for organizations standardizing storage infrastructure on IBM platforms.

IBM FlashSystem uses Spectrum Virtualize to present a unified storage interface across IBM and third-party storage arrays, enabling organizations to manage heterogeneous storage infrastructure as a single pool. This storage virtualization capability makes FlashSystem a common component in data centre consolidation programmes.

An enterprise standardizing on IBM infrastructure migrates 150 TB of file workloads from ageing Dell and NetApp NAS onto IBM FlashSystem NAS capabilities using StorageMAP, completing the vendor consolidation without impacting application access during the migration.

IBM Spectrum Scale, originally known as GPFS (General Parallel File System), is a high-performance parallel file system designed to deliver extreme aggregate throughput for data-intensive workloads by distributing both data and metadata access across many nodes simultaneously. Its purpose is to provide a shared POSIX file system that scales to petabytes and can be accessed by hundreds of compute nodes concurrently at speeds that far exceed what a single NAS appliance can provide, making it the file system of choice for HPC, AI/ML, and large-scale analytics environments. Spectrum Scale environments are encountered as migration sources in StorageMAP projects when organizations are consolidating HPC or analytics datasets to modern NAS or cloud storage.

IBM Spectrum Scale is deployed at the world’s largest scientific computing facilities including ORNL, ANL, and CERN. It supports scale-out to hundreds of petabytes with aggregate throughput exceeding 1 TB/s across large clusters.

A national weather service migrates 600 TB of archived forecast model outputs from an ageing GPFS cluster to cloud object storage using StorageMAP, freeing the GPFS cluster for active modelling workloads while preserving full metadata for archive retrieval.

Identity Mapping is the configuration of SID, UID, and GID translation rules used during a StorageMAP migration to convert user and group identity references from their source-system representation to their correct equivalents on the target system. Its purpose is to preserve the intended access control semantics of every file and directory during migration — ensuring that ownership, group membership, and ACL entries on the target grant access to the same logical users and groups as on the source, even when those users carry different numeric or binary identifiers in different directory environments. StorageMAP applies identity mapping rules file by file during the data copy phase, using mapping files uploaded as part of the migration configuration.

During a cross-domain migration following a corporate merger, 15,000 user accounts must be mapped from the acquired company’s Active Directory domain to the acquiring company’s domain. StorageMAP applies the uploaded SID map during the migration, translating every ACL entry on 2 million files and directories — a process that would require months of manual scripting effort if done without an automated mapping tool.

Identity mapping is the single most complex technical component of cross-domain file server migrations and is the primary cause of post-migration access failures when not handled systematically.

An Identity Provider (IdP) is an external authentication service integrated with StorageMAP to manage user login, session management, and role-based access control for the platform. Its purpose is to enable StorageMAP access to be governed by the organization’s existing corporate identity infrastructure — such as Active Directory, LDAP, or a SAML Single Sign-On service — rather than a standalone credential store within StorageMAP. Integrating an IdP ensures that user provisioning, password policies, multi-factor authentication requirements, and account lifecycle events (such as offboarding) are managed centrally and applied consistently to StorageMAP access alongside every other enterprise application.

Frameworks such as SOC 2 Type II, ISO 27001, and NIST 800-53 all mandate that privileged access to management systems be controlled through a centralized identity provider with MFA enforcement.

A company integrates StorageMAP with their Azure Active Directory via SAML 2.0, enabling all 15 StorageMAP administrators to log in with corporate credentials and MFA, and automatically deprovisioning access when an administrator leaves the organization — without any manual action in StorageMAP itself.

Inferencing (also called inference) is the process of running a trained machine learning model — such as a large language model or small language model — against new input data to generate predictions, completions, classifications, or answers. Its purpose is to apply the knowledge encoded in a trained model to real-world queries in production. Inferencing is distinct from training: training builds the model’s weights from large datasets, while inferencing uses those fixed weights to serve requests. In the context of enterprise data management, inferencing workloads applied to file and object content — document classification, anomaly detection, semantic search — are increasingly run adjacent to or within the storage layer, creating new latency, throughput, and data movement requirements.

Inferencing has become the dominant cost centre for enterprise AI, surpassing training expenditure as models move from development to production. GPU scarcity and inference latency requirements are driving a shift toward on-premises and edge inference deployments, particularly for workloads processing sensitive or high-volume unstructured data that cannot economically or legally be transmitted to cloud inference APIs.

A media company deploys an on-premises inference server that classifies video and image files discovered by StorageMAP across its NAS estate — tagging content by subject, sentiment, and rights status. The inference workload runs close to the storage layer to minimize data movement, and the resulting classification metadata is written back into StorageMAP’s data catalog to enrich the searchable inventory.

Running inference adjacent to storage — rather than extracting data to a remote AI platform — reduces data movement costs, lowers latency, and keeps sensitive content within the enterprise perimeter, supporting data sovereignty and compliance requirements.

An inode (index node) is the fundamental data structure used by Unix and Linux file systems to store all metadata about a file — including its type, size, owner (UID/GID), POSIX permissions, timestamps, reference count (hard link count), and the disk block addresses of its content — except for the file name itself. Its purpose is to decouple file identity from file naming, allowing multiple directory entries (hard links) to reference the same file and enabling the file system to manage files by their numeric inode identifier independently of what they are named. Each file system has a finite inode pool; environments with extremely large numbers of small files can exhaust available inodes before physical capacity is consumed, a constraint surfaced by StorageMAP’s Discovery and FSA modules during pre-migration assessment.

The inode model has been the foundational file management structure in Unix file systems since the 1970s. The default inode allocation on ext4 can be insufficient for file systems with very large numbers of small files — a common issue in log aggregation, build artifact, and genomics sequencing environments.

A StorageMAP Discovery scan of a genomics research NAS reveals that the file system is at 92% inode utilization despite only 60% capacity utilization, due to billions of small sequence files. This finding drives the migration design to specify a custom inode ratio on the target file system, preventing a repeat of the no-space-left-on-device errors that were occurring on the source despite available disk capacity.

iSCSI is a storage networking protocol that carries SCSI block-level storage commands within standard TCP/IP packets, enabling servers to access remote block storage volumes over existing Ethernet infrastructure as if the volumes were locally attached disks. Its purpose is to provide SAN-style block storage connectivity without the cost and operational complexity of dedicated Fibre Channel infrastructure, using the same Ethernet network that carries all other data traffic. While StorageMAP operates at the file and object level rather than the block level, iSCSI is commonly co-deployed in the same environments as NAS and is relevant background context for understanding the full storage infrastructure topology when planning migrations.

iSCSI was standardized in RFC 3720 (2004) and achieved widespread adoption as a cost-effective SAN protocol over standard Ethernet infrastructure. iSCSI operates on TCP port 3260 and supports CHAP authentication for initiator-target security. Jumbo frames (9000 MTU) are recommended for iSCSI networks to reduce CPU overhead.

A storage administrator migrating a NAS workload from Dell EMC Unity to Pure FlashBlade uses StorageMAP for the NAS component (NFS/SMB file data), while simultaneously migrating the Unity’s iSCSI LUNs to FlashArray using Dell EMC Live Migrate — running the two migration workstreams in parallel but managed independently.

An IP address is the numerical network label assigned to every device participating in a TCP/IP network, serving as its unique identifier and location within the network topology for purposes of routing and communication. IPv4 addresses are 32-bit values expressed as four decimal octets (e.g., 192.168.1.10), providing approximately 4.3 billion unique addresses; IPv6 addresses are 128-bit hexadecimal values providing a practically inexhaustible address space. In StorageMAP deployments, IP addresses — or the DNS-resolvable hostnames that map to them — are used to identify every managed component: the Core server, all Proxy nodes, all file servers, all object storage endpoints, and all identity providers. Correct addressing and routing between all components is a prerequisite for any StorageMAP data operation.

Industry context: IPv4 address exhaustion drove enterprise adoption of IPv6, with most modern enterprise infrastructure now supporting dual-stack (IPv4 + IPv6) operation. RFC 1918 private address spaces are universally used for internal enterprise storage networks.

Example use case: a StorageMAP deployment across three data centres uses separate RFC 1918 address ranges for each site’s storage VLAN, with Proxies deployed in each site using local addressing — ensuring that migration traffic between source and target storage systems stays within the same site’s storage VLAN and does not traverse the WAN link.

itemIsContainer is a Boolean field in DQL that evaluates to true for any scanned item that can contain child items within the storage hierarchy — including directories, mount points, DFS referrals, buckets, and object key prefixes. Its purpose is to provide a single, protocol-agnostic predicate that allows DQL queries to correctly distinguish between structural container items and leaf data items (files and objects) without requiring the query author to branch on itemtype or storage type. In practice, itemIsContainer is used to exclude containers from capacity aggregations, to build queries that work identically against both file system and object storage scan data, and to scope reporting to leaf data items only.

A DQL query calculating total capacity consumed per top-level directory uses itemIsContainer = true to identify the first directory level, then aggregates child items with itemIsContainer = false to compute each directory’s total size. Without this distinction, the query would double-count capacity for items that appear as both containers and data items.

The container/leaf distinction mirrors the concept of nodes and leaves in tree data structures, and handling it correctly is essential for producing accurate capacity reports.

A Lakehouse is a modern data architecture that combines the low-cost, flexible storage of a data lake with the transactional reliability, schema enforcement, and query performance characteristics of a data warehouse. Its purpose is to eliminate the need for separate lake and warehouse systems by enabling ACID-compliant, SQL-queryable, and machine-learning-ready workloads directly on open-format data stored in object storage. Lakehouse architectures — implemented via open table formats such as Delta Lake, Apache Iceberg, and Apache Hudi — are an increasingly common target for organisations migrating unstructured and semi-structured data from on-premises NAS, and StorageMAP supports the preparatory data movement and cataloguing required to land data into lakehouse-compatible storage.

Industry context: the lakehouse concept was formalised by Databricks in 2020 and has rapidly gained adoption as enterprises seek to converge their analytical and operational data platforms. Major cloud providers now offer lakehouse services (AWS Lake Formation, Azure Synapse Analytics, Google BigQuery), and open table formats are becoming the de facto standard for analytical data at rest.

Example use case: a retail analytics team migrates 500 TB of historical sales transaction files from on-premises NAS to Amazon S3 using StorageMAP, then registers the S3 prefix with an Apache Iceberg catalog. The resulting lakehouse table enables the data science team to query ten years of transactional history directly in SQL without replatforming the data into a separate warehouse, reducing infrastructure costs by 60%.

Benefit: the lakehouse architecture reduces data duplication by serving both BI reporting and machine learning workloads from the same underlying storage layer, and open table formats ensure that data is not locked into a proprietary platform — a significant advantage for long-term data portability and vendor flexibility.

A Landing Zone is a designated, pre-configured storage area — typically in a cloud or object storage environment — that serves as the initial destination for data ingested from external sources, migration pipelines, or upstream processing systems. Its purpose is to provide a controlled, observable staging area where data can be received, validated, catalogued, and prepared before being moved to its final storage tier or processing environment. In StorageMAP migration workflows, a landing zone commonly acts as the cloud target into which files and objects are replicated during iterative copy rounds, before switchover directs production workloads to the new location.

Landing zones are a foundational pattern in cloud data architecture, formalized by AWS, Azure, and GCP as the recommended entry point for large-scale data ingestion and migration. The concept extends the traditional staging area pattern to cloud-native storage, and is a prerequisite for well-governed data lake and lakehouse architectures.

A media company migrating 2 PB of video assets from on-premises NAS to Amazon S3 provisions a dedicated S3 prefix as a landing zone. StorageMAP replicates files incrementally into the landing zone over several weeks, and post-copy validation scripts verify checksums before the landing zone is promoted to the production media archive bucket.

Configure landing zone storage with appropriate lifecycle policies, encryption at rest, and access controls from the outset — it is much easier to enforce governance on data as it arrives than to apply it retrospectively. Treat the landing zone as temporary by default and define a clear promotion or deletion path for every dataset that passes through it.

A Large Language Model (LLM) is a deep learning model trained on vast corpora of text data that is capable of understanding, generating, and reasoning about natural language at a level approaching human fluency. Its purpose is to enable a broad range of language tasks — summarisation, question answering, code generation, translation, and conversation — without task-specific training. LLMs such as GPT-4, Claude, Gemini, and LLaMA are increasingly being applied to enterprise unstructured data — documents, emails, contracts, reports — and the storage infrastructure required to support LLM training, fine-tuning, and inferencing workloads represents a significant new demand on data management platforms.

LLMs have moved from research curiosity to enterprise production workload in under two years, with IDC estimating that AI infrastructure spending exceeded $100 billion globally in 2024. Organizations training or fine-tuning LLMs on proprietary data must address data governance, access control, and lineage challenges — areas where StorageMAP’s data catalog and DAG capabilities provide foundational support.

A professional services firm fine-tunes an open-source LLM on its proprietary engagement documents. StorageMAP is used to discover, classify, and export the relevant files from NAS storage — ensuring that only appropriately governed, non-sensitive content is included in the training corpus — and to maintain an auditable record of which data was used for model training.

Establish data governance controls over LLM training data before model development begins. Data that is ingested into an LLM’s weights is effectively non-extractable after training, making pre-ingestion classification and consent verification — supported by StorageMAP’s cataloging and access governance capabilities — essential for compliance with data protection regulations.

LDAP (Lightweight Directory Access Protocol) is an open, vendor-neutral protocol for reading and writing entries in distributed directory information services — such as Microsoft Active Directory, OpenLDAP, and IBM Security Directory Server — over TCP/IP on port 389 (plaintext) or 636 (LDAPS, encrypted). Its purpose is to provide a standardized programmatic interface that applications can use to authenticate users, retrieve group membership information, and look up user attributes from a directory server without being tied to any particular vendor’s proprietary API. StorageMAP uses LDAP to integrate with enterprise directory services for administrator and user login, for role-based access control group resolution, and for user identity lookups during analytics and reporting.

LDAP was standardized in RFC 4511 (2006) and is the universal protocol for directory service access. Microsoft Active Directory exposes LDAP on port 389 and LDAPS (LDAP over TLS) on port 636. RFC 2307 defines how POSIX attributes (UID, GID, home directory) are stored in LDAP directories, enabling NFS servers to resolve UID/GID to LDAP user entries.

StorageMAP is integrated with an organization’s OpenLDAP directory via LDAPS, enabling all 25 storage administrators to log in with their corporate credentials and enforcing RBAC policies that limit junior administrators to read-only analytics access.

Load balancing is the distribution of network traffic or processing workloads across multiple resources — such as servers, network links, or processing nodes — to prevent any single resource from becoming a bottleneck and to maximize aggregate throughput and availability. Its purpose is to improve scalability and resilience by spreading demand across a pool of capacity so that no single component limits performance or becomes a single point of failure. In StorageMAP, deploying multiple Proxy nodes provides inherent load balancing for data operation workloads — migration, replication, and scan jobs can be distributed across Proxies based on proximity, capacity, and current workload — improving overall platform throughput and enabling large-scale operations to run concurrently without resource contention.

For StorageMAP specifically, load balancing at the Proxy level is achieved through job assignment rather than traditional network load balancing — StorageMAP’s job scheduling distributes scan and migration workloads across available Proxies based on configured assignments.

A large migration programme running 12 concurrent migration jobs deploys 6 Proxy nodes, assigning 2 jobs per Proxy to balance load. When one Proxy is taken offline for maintenance, its jobs are paused and reassigned to an available Proxy — demonstrating the resilience of the distributed Proxy architecture.

Metadata, in its broadest storage context, is any data that describes, characterizes, or provides context about other data — without being the data itself. Its purpose is to make stored data discoverable, manageable, securable, and governable at scale: without metadata, a storage system containing billions of files would be an undifferentiated mass of bytes with no means of locating, identifying, or acting on individual items. Storage metadata includes file system metadata (name, path, size, timestamps, permissions), object metadata (key, ETag, storage class, user-defined pairs), and administrative metadata such as replication status and retention lock state. StorageMAP’s entire analytics, classification, optimization, and migration capability is built on the collection, indexing, and querying of storage metadata — it never needs to read file content to deliver its core value.

Storage metadata has become a critical strategic asset — the EU’s Data Governance Act (DGA) and US Federal Data Strategy both identify metadata cataloguing as a prerequisite for effective enterprise data management and AI readiness. Major cloud providers (AWS Glue Data Catalog, Azure Purview, Google Dataplex) have invested heavily in metadata management platforms.

StorageMAP’s metadata-only approach to analytics provides a practical privacy

It enables full data visibility and governance reporting across datasets containing personal data subject to GDPR restrictions, without triggering any data processing concerns.

Microsoft Azure is Microsoft’s cloud computing platform, the world’s second largest by market share, providing a broad portfolio of infrastructure, platform, and software services from globally distributed data centers. Its purpose is to enable organizations to build, deploy, and manage cloud applications with deep integration into Microsoft’s ecosystem of identity services (Active Directory), productivity tools (Microsoft 365), and enterprise software. Azure is a primary destination for StorageMAP cloud migration projects, with Azure Blob Storage, Azure Files, Azure NetApp Files, and Azure Data Lake Storage serving as the main storage endpoints for migrated data.

Azure holds approximately 24% of the global cloud market (2024) and is the dominant cloud platform for Microsoft-centric enterprises running Office 365, Teams, and Azure Active Directory.

A global law firm migrates 400 TB of Windows file server data from on-premises Dell EMC Unity to Azure Files Premium using StorageMAP, integrating Azure Files with their Azure Active Directory to preserve all SMB ACLs and enabling lawyers globally to access client files from Azure-connected offices with identical permissions.

A Migration is the process of transferring data — including files, directories, objects, metadata, and permissions — from a source storage system to a target, with the goal of retiring the source and redirecting all workloads to the new platform. Its purpose is to enable storage infrastructure refreshes, vendor transitions, data center consolidations, and cloud transformations without data loss, permission degradation, or extended downtime. StorageMAP manages the full migration lifecycle through iterative incremental synchronization rounds that minimize the data gap at Switchover, followed by identity mapping, share and export recreation, and a controlled cutover that redirects user access to the target.

According to IDC, enterprises replace storage systems on a 5 to 7 year refresh cycle, making data migration a recurring operational reality.

Following an acquisition, a pharmaceutical company must consolidate 40 NAS systems from the acquired entity onto its existing NetApp ONTAP estate within 6 months — a project that StorageMAP completes with 99.97% data fidelity across 12 PB.

Iterative incremental migration reduces application downtime at Switchover to minutes rather than hours, directly reducing business disruption and SLA risk.

A Migration Rollback is a recovery procedure used to reverse the effects of a completed migration and restore data access via the original source environment when post-migration issues — such as missing files, broken permissions, or application incompatibilities — are discovered after Switchover. Its purpose is to provide a structured safety net that protects business continuity if the target system proves unsuitable or a critical defect emerges that cannot be resolved within an acceptable timeframe on the target. Rollback procedures are defined as part of migration planning and typically involve redirecting client access back to the source and, where necessary, reverse-syncing any data written to the target during the migration window.

Example use case: after a weekend migration of a finance application’s file server, users report that an accounts payable application cannot locate its data files due to an unexpected path mapping error. The rollback procedure re-points DNS to the source within 20 minutes, restoring full user access while the target configuration is corrected for a re-migration the following weekend.

Best practice: always document and test the rollback procedure as part of migration planning, and never decommission the source system until the target has been validated in production for at least one full business cycle.

MinIO is a high-performance, open-source S3-compatible object storage platform available as free self-hosted software deployable on Linux, Kubernetes, or bare metal, as well as a commercially supported enterprise edition and a managed cloud service — recognized as the most widely deployed open-source object storage platform in the world by instance count. Its purpose is to provide a lightweight, operationally simple S3-compatible object store that can be deployed in any environment from a single developer machine to a large distributed production cluster, with performance characteristics suited to AI/ML data pipelines, analytics, and cloud-native applications. MinIO is a commonly encountered endpoint in StorageMAP O2O migration workflows, both as a source when organizations migrate away from self-managed object storage and as a target when building private cloud storage infrastructure.

MinIO has over 1 billion Docker pulls and is deployed in thousands of organisations as a lightweight, self-managed S3 store. Its performance has been benchmarked at over 325 GiB/s throughput on standard NVMe hardware. MinIO’s open-source model (AGPL-3.0) allows free deployment for non-commercial use.

A technology company builds an on-premises AI training data lake using MinIO deployed on commodity NVMe servers, and uses StorageMAP to migrate 500 TB of training datasets from legacy NAS to MinIO S3, enabling GPU clusters to access training data directly via the S3 API at 100 GiB/s aggregate throughput.

mtime, or modification time, is the file system timestamp that records the most recent moment at which a file’s content was written or truncated by any process. Its purpose is to serve as the definitive, reliable indicator of when data was last changed from a content perspective, making it the most important timestamp for data management decisions such as cold data classification, retention eligibility assessment, and incremental synchronization during migrations. In StorageMAP, mtime is the primary timestamp used in cold data conditions within the Storage Optimizer and in age-based filters and classifiers, and it is the default ordering field for analyses focused on identifying stale or untouched data.

mtime is the primary timestamp used by backup software, replication engines, and data management platforms to detect changed files for incremental processing. All major backup platforms — Veeam, Commvault, Veritas NetBackup, and Cohesity — use mtime as the primary change detection signal.

StorageMAP uses mtime during incremental migration synchronization rounds to identify only the files changed since the previous pass, reducing the delta scan time from hours (for a full scan) to minutes (for a changed-file scan) on large file systems with low daily change rates.

A Multi-Protocol (MUP) migration is a StorageMAP migration job that coordinates data transfer across multiple protocols simultaneously, enabling NAS and object storage data to be migrated within a single managed operation. Its purpose is to simplify complex migrations where a source environment exposes data through multiple protocol access paths — for example, a NAS system that serves the same dataset over both SMB and NFS — ensuring that all protocol-specific metadata, permissions, and access paths are reproduced faithfully on the target without requiring separate, independently managed migration jobs. MUP migrations reduce operational overhead and ensure consistency between protocol views of the migrated data.

A manufacturing company’s CAD file server is accessed by Windows workstations over SMB and by Linux rendering nodes over NFS simultaneously. A MUP migration ensures that both the NTFS ACLs and POSIX permissions are correctly reproduced on the target, with a single consistent dataset rather than two separate migration jobs that risk producing divergent data states.

MUP migrations reduce the operational complexity and risk of migrating heterogeneous access environments, which are prevalent in engineering, research, and media organizations.

A NAS-to-NAS (N2N) migration is a data transfer operation that moves files, directories, and associated metadata from one network-attached storage system to another over file-sharing protocols. Its purpose is to enable file server refreshes, NAS vendor transitions, and storage consolidations while fully preserving the structure and integrity of the file system — including permissions, timestamps, ownership, ACLs, and directory hierarchies. StorageMAP performs N2N migrations over SMB for Windows environments and NFS for Unix/Linux environments, and manages the complete workflow from initial scan through incremental synchronization rounds, identity mapping, share recreation, and final Switchover.

N2N migration is the most common migration type in enterprise environments, accounting for the majority of storage refresh projects.

A financial institution migrates 600 TB from a Hitachi HNAS system to NetApp AFF over eight weeks, using StorageMAP to run nightly incremental synchronization rounds and achieve a final Switchover window of under 4 minutes.

The preservation of all NTFS ACLs, POSIX permissions, and SACL audit configurations ensures zero regression in security posture after the migration — a critical requirement in regulated industries.

NetApp is one of the world’s leading enterprise storage vendors, known primarily for its ONTAP storage operating system and a broad portfolio of NAS, SAN, object, and cloud storage products deployed across virtually every industry. Its purpose in the storage market is to deliver data management infrastructure that combines high performance, comprehensive data protection, and operational efficiency across on-premises and multi-cloud environments under a consistent management model. NetApp ONTAP-based systems — FAS, AFF, Cloud Volumes ONTAP, and Amazon FSx for NetApp ONTAP — are among the most frequently encountered platforms in StorageMAP migration and analytics deployments, and are supported as integrated (native API) file servers for enhanced management fidelity and automated share/export provisioning.

NetApp holds approximately 20% of the global external storage market (IDC, 2024) and is the most widely deployed enterprise NAS vendor globally. NetApp’s storage systems manage an estimated 40% of the world’s enterprise file data.

StorageMAP’s native ONTAP API integration is used in the majority of enterprise migration projects involving NetApp systems, enabling automated volume discovery, share recreation, and post-migration validation that would otherwise require manual ONTAP CLI operations.

NetApp AFF (All Flash FAS) is NetApp’s all-NVMe and all-SSD storage array product line running ONTAP, designed to deliver the highest NAS and SAN performance available within the ONTAP ecosystem with the full enterprise data management feature set. Its purpose is to serve as the high-performance primary storage tier in modern ONTAP environments, providing sub-millisecond latency, high IOPS density, and aggressive inline storage efficiency for business-critical workloads. NetApp AFF is a common migration target in StorageMAP projects where organizations are consolidating workloads from multiple aging NAS platforms onto modern all-flash infrastructure while preserving ONTAP’s operational model.

ΩNetApp AFF was the first all-flash NAS platform to achieve hyperconverged multiprotocol storage (NFS, SMB, iSCSI, NVMe-oF) on a single platform at enterprise scale. The AFF A-Series (performance) and C-Series (capacity flash) address different price-performance points within the all-flash market.

A banking institution consolidates 40 legacy NAS systems onto six NetApp AFF A900 nodes using StorageMAP to migrate data from each legacy system in parallel, completing a 3-year storage refresh programme in 14 months rather than the 24 months estimated for sequential migrations.

NetApp Cloud Volumes ONTAP (CVO) is a software-defined version of the ONTAP operating system that runs as a virtual appliance on AWS, Azure, or Google Cloud, delivering the full ONTAP feature set — NFS, SMB, iSCSI, snapshots, SnapMirror, deduplication, and compression — on cloud VM infrastructure without dedicated storage hardware. Its purpose is to allow organizations to extend their ONTAP data management practices, tooling, and operational model into the cloud, providing a familiar enterprise NAS environment on cloud compute that can be SnapMirror-replicated from on-premises for disaster recovery or used as a migration landing zone. StorageMAP migrations to Cloud Volumes ONTAP preserve ONTAP-native metadata and enable organizations to maintain ONTAP management consistency after cloud transition.

Cloud Volumes ONTAP is the only cloud storage solution that provides complete ONTAP data services — including SnapMirror, FlexClone, deduplication, and compression — across AWS, Azure, and GCP simultaneously.

A pharmaceutical company runs its ONTAP-dependent Electronic Lab Notebook application on Cloud Volumes ONTAP in AWS, and uses StorageMAP to migrate 60 TB of legacy research data from on-premises FAS into CVO as part of a cloud transformation programme.

NetApp FAS (Fabric-Attached Storage) is NetApp’s hybrid storage array product line, combining hard disk drives and solid-state drives under the ONTAP operating system to deliver cost-effective, enterprise-grade NAS and SAN storage for mixed workloads. Its purpose is to provide a balance of capacity, performance, and rich ONTAP data services at a lower cost point than all-flash arrays, making it well suited for backup targets, home directories, archive tiers, and secondary workloads. NetApp FAS systems are a common source platform in StorageMAP migration projects as organizations refresh aging infrastructure by migrating to newer all-flash arrays, cloud-based ONTAP, or object storage.

FAS systems can be equipped with the FabricPool feature, which automatically tiers cold ONTAP data to object storage (S3, StorageGRID) at the block level — providing native cold data tiering without requiring StorageMAP data movement. However, FabricPool tiering is invisible to analytics tools, making StorageMAP scans of FabricPool-enabled volumes important for understanding the true logical data distribution.

A company replaces its end-of-life FAS8040 with a new AFF C-Series using StorageMAP for the migration, using StorageMAP’s incremental sync capability to reduce the final Switchover window to under 10 minutes despite a 150 TB dataset.

NetApp ONTAP is the proprietary storage operating system that powers NetApp’s FAS hybrid arrays, AFF all-flash arrays, ONTAP Select software-defined deployments, Cloud Volumes ONTAP, and Amazon FSx for NetApp ONTAP. Its purpose is to provide a unified, enterprise-grade storage platform supporting NAS (NFS and SMB), SAN (iSCSI, FCP, NVMe-oF), and object (S3) protocols from a single operating system, with integrated data services including snapshots, SnapMirror replication, deduplication, compression, encryption, and multi-tenancy through Storage Virtual Machines. StorageMAP integrates with ONTAP at the native management API level, enabling richer operations during migrations — including automated volume, share, and export creation — than are possible through protocol-only access.

ONTAP has been the dominant enterprise NAS operating system for over 25 years. ONTAP 9.x introduced S3 protocol support, NVMe-oF, and cloud tiering via FabricPool. ONTAP’s SnapMirror replication technology is the most widely deployed NAS replication solution in enterprise environments.

A manufacturing company running ONTAP 8.3 on FAS6200 hardware must migrate 300 TB to a new AFF A400 running ONTAP 9.12. StorageMAP manages the migration via NFS and SMB protocols simultaneously, preserving all metadata and permissions while the ONTAP teams separately manage the new cluster configuration.

NetApp StorageGRID is an enterprise-grade software-defined object storage platform for on-premises deployment at petabyte scale, providing full S3 API compatibility alongside advanced data management features including information lifecycle management (ILM) policies, geo-distributed replication, and compliance-grade retention lock. Its purpose is to give organizations a private cloud object storage solution that delivers the scalability and API compatibility of public cloud services while keeping data on-premises for sovereignty, latency, compliance, or cost reasons. StorageGRID is supported as an object storage endpoint in StorageMAP O2O migrations and data actions, used both as a source when migrating data to cloud and as a target when building an on-premises object storage tier.

NetApp StorageGRID is the most widely deployed enterprise on-premises object storage platform globally, used by financial services, healthcare, and public sector organizations that require S3 API compatibility without public cloud dependencies.

A major insurance company uses StorageGRID as its on-premises archive tier, and uses StorageMAP to migrate cold data from primary NAS to StorageGRID on a quarterly schedule — processing 80 TB per quarter and reducing primary NAS growth from 25% to 8% annually.

Network File System (NFS) is an open, IETF-standard distributed file-sharing protocol used to provide Unix/Linux clients with transparent access to remote file systems over a TCP/IP network, presenting remote directories as part of the local file system hierarchy using standard POSIX semantics. Its purpose is to enable cross-platform, multi-client file sharing for Unix/Linux workloads while preserving the UID/GID ownership, POSIX permission bits, and timestamp metadata that Unix applications expect. StorageMAP uses NFS to access source and target file servers during Unix/Linux NAS migrations, with support for NFSv3 (stateless, widely compatible) and NFSv4/4.1 (stateful, Kerberos-capable, supports named attributes) depending on the platform and migration requirements.

NFS was created by Sun Microsystems in 1984 and is now maintained by IETF. NFSv3 (RFC 1813, 1995) remains the most widely deployed version due to its simplicity and broad vendor support. NFSv4.1 (RFC 5661, 2010) adds pNFS (parallel NFS) — allowing clients to read/write directly from/to storage nodes in parallel — enabling throughput beyond what a single NAS head can provide.

A research HPC cluster migrates from NFSv3 to NFSv4.1 on a new NetApp ONTAP system using StorageMAP for the data transfer phase, enabling 3x higher aggregate NFS throughput on the new platform.

Network-Attached Storage (NAS) is a category of dedicated storage devices connected to a TCP/IP network that provide shared file-level access to multiple clients simultaneously through standard file-sharing protocols. Its purpose is to centralize unstructured data — documents, media, application data, and home directories — onto a managed, shared storage system that can be administered, protected, and scaled independently of individual clients. NAS presents storage as a hierarchical namespace of directories and files accessible via SMB for Windows clients and NFS for Unix/Linux clients, and it is the primary class of storage system that StorageMAP manages for scanning, migration, replication, and data lifecycle operations.

The NAS market is one of the largest segments of enterprise storage infrastructure, with IDC estimating over $20 billion in annual revenue. NAS adoption is driven by the explosive growth of unstructured data — AI/ML datasets, collaboration documents, media files, and application outputs — projected to grow at 23% CAGR through 2027.

A law firm with 40 TB of active matter files, 200 TB of closed matter archives, and 15 TB of email archives across three Dell EMC Unity NAS systems uses StorageMAP to gain unified visibility, identify 180 TB eligible for archive tiering, and migrate the full estate to a consolidated NetApp ONTAP system within a 10-week project window.

An object key is the unique string identifier assigned to an object within a bucket in an object storage system, functionally equivalent to a file path in a hierarchical file system but stored in a flat namespace where the key is the sole addressing mechanism. Its purpose is to provide each object with a unique, retrievable address within its bucket that allows any object to be accessed directly given only its bucket name and key, regardless of the total number of objects in the system. Object keys commonly contain forward slashes to simulate directory hierarchy for organizational purposes, and StorageMAP represents object keys in the path field of DQL scan output, consistent with how file paths are handled for file system sources.

Object key design has significant operational implications — well-designed key schemas facilitate cost-effective storage and efficient prefix-based queries.

Include date components early in the key hierarchy to enable efficient time-based lifecycle policies and prefix-scoped queries. Poorly designed keys (e.g., sequential numeric keys) can cause hot-spotting in some S3 implementations. StorageMAP preserves object keys verbatim during O2O migrations, ensuring that all existing application references and lifecycle policies remain valid on the target.

Object metadata is the descriptive information associated with an object in an object storage system, stored alongside the object’s content but retrievable independently via the storage API. Its purpose is to provide addressing, integrity verification, lifecycle management, and application-defined context for stored objects without requiring their full content to be read. Object metadata divides into system-managed fields — including the object key, size, ETag, last modification time, storage class, and version ID — and optional user-defined key-value pairs set by the application at upload time to encode business or application context. StorageMAP reads both categories of object metadata during scans and preserves all metadata fields faithfully during O2O migrations.

Object metadata interoperability is governed by the S3 API standard, which defines system metadata fields that every S3-compatible platform must support.

A media asset management system stores rendering status, project ID, and codec information as user-defined metadata on every video object in S3. StorageMAP preserves all these custom metadata fields during an O2O migration to a new object storage platform, ensuring that the media management application continues to function correctly on the target without any re-tagging effort.

Object Storage in StorageMAP refers to any S3-compatible storage endpoint — cloud or on-premises — registered in the platform as a source or target for object-level data operations. Its purpose is to extend StorageMAP’s management and migration capabilities to the flat-namespace, API-accessed world of object storage alongside its traditional file system capabilities. Object Storage endpoints are configured with S3 endpoint URLs, access credentials, and optional bucket scoping, and serve as the source or target for O2O Migration jobs, object Data Actions, and object Replication workflows within the platform.

The global object storage market is projected to exceed $150 billion by 2030, driven by cloud adoption and the growth of unstructured data from IoT, AI/ML, and media workloads. S3 has become the universal interface for object storage, with compatibility available from over 30 vendors.

A genomics research institute registers its on-premises NetApp StorageGRID and its AWS S3 research data bucket as Object Storage endpoints in StorageMAP, enabling unified visibility and analytics across 8 PB of genomics data regardless of whether it resides on-premises or in the cloud.

An Object-to-Object (O2O) migration is a data transfer operation that moves objects and their associated metadata from one object storage system to another using the S3 protocol. Its purpose is to support cloud migrations, on-premises object storage consolidations, and platform transitions while preserving the full object metadata including keys, ETags, user-defined metadata, storage classes, and optionally version histories. StorageMAP executes O2O migrations with iterative incremental synchronization to minimize the data delta at the point of cutover and ensure that the target is a complete and accurate replica of the source at the moment of transition.

Industry context: as multi-cloud and hybrid cloud strategies mature, O2O migrations are increasingly common — moving data between hyperscalers, consolidating object storage platforms, or repatriating data from cloud to on-premises.

Example use case: a media company migrates 2 PB of video assets from an ageing on-premises Scality RING to AWS S3, using StorageMAP to verify every object via ETag comparison and assign the correct S3 storage class during the migration.

Benefit: S3-protocol universality means that StorageMAP’s O2O engine works unchanged regardless of which two S3-compatible platforms are involved.

OneFS is the proprietary clustered file system operating system that powers all Dell EMC Isilon and PowerScale NAS clusters, managing a pool of cluster nodes as a single, unified file system with one global namespace, one address space, and one management interface. Its purpose is to abstract the complexity of a multi-node storage cluster entirely from clients and administrators, handling all aspects of data distribution, erasure-coded protection, protocol access (NFS, SMB, S3, HDFS), and performance across nodes transparently. StorageMAP integrates with OneFS through its native API for enhanced scan and migration capabilities, and OneFS-specific constructs such as access zones and protocol configurations are accounted for in migration planning.

Industry context: OneFS is unique among NAS operating systems in providing a true single namespace across all nodes in a cluster without volume managers, aggregates, or mount points — a simplicity that sets it apart from ONTAP’s volume-based architecture. OneFS uses a proprietary file protection scheme (FlexProtect) that is more space-efficient than RAID-6 for large clusters.

Example use case: a broadcast company migrates from an older Isilon NL400 series to a new PowerScale H700 using StorageMAP, preserving all OneFS-specific directory junction points, DFS referrals, and access zone configurations in the migration design.

An ONTAP Storage Virtual Machine (SVM), also called a Vserver, is a logical partition within a NetApp ONTAP cluster that presents an independent, isolated storage environment with its own network interfaces, namespace, volumes, protocol configurations, and security settings. Its purpose is to enable multi-tenancy on a shared physical ONTAP cluster, allowing multiple independent NAS server contexts — each with their own DNS name, IP addresses, and data sets — to coexist on the same hardware without interfering with one another. StorageMAP configures NetApp file servers at the SVM level, treating each SVM as a distinct managed endpoint, and migration operations interact with each SVM’s share, export, and volume configuration through the ONTAP management API.

Industry context: SVM architecture enables the consolidation of hundreds of individual file servers — each previously a separate physical appliance — onto a shared ONTAP cluster with full isolation between tenants.

Example use case: a shared-services organisation hosts 120 customer SVMs on a single ONTAP cluster, each managed independently by StorageMAP as a distinct file server, enabling per-customer migration and analytics workflows without cross-tenant visibility.

An ONTAP volume is a logical storage container within a NetApp ONTAP SVM that hosts a file system namespace and is the primary unit of data organization and policy application in ONTAP. Its purpose is to provide an independently configurable storage unit to which capacity quotas, security styles, snapshot schedules, QoS policies, deduplication settings, tiering policies, and protection relationships can be applied at a granular level. NFS exports and SMB shares are defined within or mapped from volumes, making the volume the organizational boundary that determines how data is accessed, protected, and managed. StorageMAP migration jobs are typically scoped at the volume level for ONTAP source systems.

ONTAP volumes support thin provisioning, allowing volumes to be sized larger than the physical storage immediately available. The total provisioned size of all volumes on an ONTAP system commonly exceeds physical capacity by 2 to 3 times in well-managed deployments.

A StorageMAP Discovery scan of a NetApp FAS system identifies 22 volumes, of which 8 are over 85% full and 6 have not been modified in over two years. This analysis directly informs the target ONTAP volume sizing and layout for the migration.

A Paused Job is a StorageMAP migration, replication, or data action job that has been deliberately suspended mid-execution, halting all data transfer activity while retaining full job state and progress for later resumption. The ability to pause jobs exists to give administrators precise operational control over when resource-intensive data movement occurs — for example, pausing a migration during business hours to preserve network bandwidth for production traffic and resuming it in the off-peak window. StorageMAP tracks all paused jobs centrally and allows resumption from the last completed checkpoint without restarting the entire operation.

A migration engineer notices at 8:45 AM that a migration job is consuming 70% of the production network link. They pause the job immediately — which takes effect within seconds — and configure a Throttling schedule to prevent recurrence. The job resumes automatically at 6 PM under the off-peak throttle policy.

Design Throttling schedules proactively so that jobs never need to be paused manually during business hours, reserving manual pause as an emergency control for unexpected situations.

A network port is a 16-bit numerical endpoint identifier used in TCP and UDP communications to direct incoming traffic to the specific application or service listening on that port on a given host. Its purpose is to enable a single IP address to host multiple independent network services simultaneously, with each service bound to a different well-known or application-defined port number. Key ports relevant to StorageMAP environments include TCP 445 (SMB), TCP 2049 (NFSv4), TCP 111 (NFS portmapper), TCP 443 (HTTPS/S3 over TLS), TCP 389 (LDAP), and TCP 636 (LDAPS). Firewall rules in enterprise environments are typically configured at the port level, and a complete port-by-port firewall rule set between all StorageMAP components and managed storage systems must be validated before any data operation can succeed.

The IANA maintains the official registry of well-known ports (0 to 1023), registered ports (1024 to 49151), and dynamic ports (49152 to 65535). Firewall rules for storage environments typically cover TCP 445 (SMB), TCP/UDP 2049 (NFS), TCP/UDP 111 (rpcbind/portmapper for NFSv3), TCP 443 (HTTPS/S3), and TCP 389/636 (LDAP/LDAPS).

A StorageMAP pre-deployment checklist includes port connectivity tests from the Core server to all managed file servers, from each Proxy to source and target file servers, and from administrator workstations to the Core web interface — with results documented as evidence of network readiness.

POSIX permissions are the Unix/Linux standard access control mechanism for files and directories, consisting of three sets of read, write, and execute bits applied to three identity classes: the file’s owning user, the file’s owning group, and all other users. Their purpose is to enforce a simple, computationally efficient discretionary access control model at the file system level, controlling who may read, modify, or execute each file through a compact three-digit octal representation (e.g., 755). POSIX permissions are stored as part of the file’s inode and are the foundational access control layer for all NFS-based NAS environments. StorageMAP reads and preserves POSIX permissions during NFS migrations, and reports permission and ownership details through its DQL scan interface.

POSIX.1-2017 defines the standard permission model for Unix/Linux systems, forming the basis for access control across all major NFS-capable NAS platforms. Even vendors such as NetApp (ONTAP) and Dell (OneFS) that support NTFS-style ACLs also support POSIX permissions through their mixed security style model.

A research university migrates 600 TB of research data from an old Linux NFS server to a NetApp ONTAP system. StorageMAP preserves all POSIX permissions and UID/GID ownership, and researchers find that their file access permissions are identical on the new platform — enabling a seamless migration with no access reconfiguration required.

A Post Finish Action is a configurable set of automated steps executed by StorageMAP after a migration job completes its data transfer phase, used to verify data integrity, repair discrepancies, or generate completion documentation. Its purpose is to automate the post-migration validation and close-out tasks that would otherwise require manual administrator effort after every job, ensuring that quality assurance steps are consistently applied. Post Finish Actions may include integrity verification scans, automatic repair of skipped or errored items, and the generation of job summary reports suitable for audit trails or client sign-off deliverables.

A service provider uses Post Finish Actions to automatically generate a Chain of Custody report and a skipped-items repair run at the conclusion of each migration job. The completion report is automatically emailed to the client’s project manager, providing immediate evidence of migration success without requiring a manual reporting step.

Automated post-migration validation aligns with ISO 27001 change management controls that require evidence of controlled, verified change outcomes.

In object storage, a Prefix is the leading portion of an object key up to a delimiter character — typically a forward slash — that simulates a directory level in the otherwise flat namespace of a bucket. Because object storage has no real directory hierarchy, prefixes are a client-side convention for organizing objects into logical groups that tools and interfaces can display as if they were folders. In StorageMAP’s DQL output, prefix items are reported as a distinct itemtype to allow hierarchical navigation and folder-level capacity aggregations over object storage scans, enabling DQL queries designed for file system data to be applied consistently to object storage environments.

A DQL analysis of a 500-million-object S3 bucket uses prefix-level aggregation to produce a top-down capacity breakdown by simulated folder, revealing that a single prefix accounts for 60% of the bucket’s total capacity — a finding that directly identifies the highest-value target for a Glacier tiering action.

The convention of using forward slashes as key delimiters to simulate directories is universally adopted across S3-compatible platforms and is integral to how tools such as the AWS Console and S3 Browser navigate object storage.

A Proxy is a distributed worker component in the StorageMAP architecture that performs the actual data operations — including scanning, migrating, replicating, and copying — on behalf of the Core server. Its purpose is to scale StorageMAP performance and extend its operational reach to different network segments or geographic locations without routing all data traffic through the Core. Proxies are deployed close to the storage systems they serve, registered to the Core, and can be distributed across multiple nodes to parallelize workloads, increase throughput, and isolate traffic between network zones.

In a cross-datacenter migration where source NAS is in London and the target is in an AWS region in Ireland, a Proxy deployed in Ireland handles all data ingest from the source over a dedicated MPLS link, keeping Core traffic minimal.

Distributed Proxies allow throughput to scale linearly — doubling the Proxy count in a well-designed network approximately doubles aggregate migration bandwidth.

Deploy at least two Proxies per migration for redundancy and workload distribution.

Pure Storage is an enterprise all-flash storage vendor known for its FlashArray (block and unified storage) and FlashBlade (file and object) product lines and its Evergreen subscription model that allows hardware upgrades without data migration or downtime. Its purpose is to provide high-performance, operationally simple enterprise storage with predictable performance and guaranteed data reduction, eliminating the operational complexity of traditional storage systems. Pure Storage FlashBlade supports NFS, SMB, and S3 protocols for unstructured data workloads and is a supported StorageMAP migration target for organizations consolidating high-performance NAS and object storage onto modern all-flash infrastructure.

Pure Storage pioneered the Evergreen Storage subscription, which guarantees storage administrators they will never need to migrate data off Pure hardware — hardware components are upgraded in place without downtime. Pure Storage FlashArray//C provides capacity flash (QLC NAND) at approximately 40% lower cost per TB than FlashArray//X (TLC NAND).

A digital media company migrates 800 TB from an ageing NetApp FAS cluster to Pure FlashBlade using StorageMAP, achieving a 5x throughput improvement for video rendering workloads and reducing storage management time from 15 hours per week to under 2 hours.

Pure Storage FlashBlade is an all-flash, scale-out storage system purpose-built for high-performance unstructured data workloads, combining NAS file serving (NFS and SMB) and object storage (S3) on a single platform optimized for massive parallel throughput. Its purpose is to serve as the storage foundation for AI/ML training data pipelines, genomics analysis, financial risk calculations, media rendering, and other data-intensive workloads where aggregate read/write throughput across millions of simultaneous small or large I/Os is the primary performance requirement. FlashBlade is a supported StorageMAP migration target, enabling organizations to migrate NAS or object data from legacy or slower platforms onto high-performance flash infrastructure using NAS-to-NAS or O2O migration workflows.

FlashBlade is unique in the market for its ability to serve NAS (NFS, SMB) and object (S3) workloads from the same hardware pool, eliminating the need for separate NAS and object storage systems. FlashBlade’s DirectFlash technology bypasses standard SSD controllers to access NAND flash directly, achieving higher throughput and lower latency than competing all-flash NAS platforms.

A pharmaceutical company migrates its HPC genomics data from IBM Spectrum Scale to Pure FlashBlade using StorageMAP, achieving 3x higher sequencing pipeline throughput due to FlashBlade’s parallel NFS access model.

A qtree is a logical subdirectory within a NetApp ONTAP volume that can be independently configured with its own security style (UNIX, NTFS, or Mixed), quota limits, and NFS export or SMB share access paths — effectively functioning as a lightweight, semi-autonomous container within a volume. Its purpose is to provide finer-grained data organization and security segmentation within a volume, allowing multiple independently governed datasets to share a single volume without requiring separate volumes for each. Qtrees are a NetApp-specific construct that StorageMAP handles natively during ONTAP migrations, preserving security styles and mapping qtree-level paths to the correct target structure on destination systems.

Qtrees are a legacy NetApp architectural element predating modern ONTAP volumes and are still prevalent in ONTAP installations that have been in service since the Data ONTAP 7-mode era. In current ONTAP 9.x, qtrees are still used for quota management and export/share granularity within large volumes.

A StorageMAP pre-migration Discovery of a 7-mode era NetApp system reveals 340 qtrees across 12 volumes, each with independently configured NFS exports and Windows ACL security styles. StorageMAP correctly maps each qtree as a separate migration source path, preserving the per-qtree security style on the ONTAP 9 target.

Qumulo is a scale-out file storage vendor that provides a software-defined NAS platform deployable on commodity hardware on-premises and natively on AWS (Cloud Q), Azure, and Google Cloud, supporting NFS and SMB protocols with real-time storage analytics built directly into the operating system. Its purpose is to provide a modern, cloud-flexible file storage platform with live visibility into performance, capacity, and activity at the file system level — eliminating the need for external monitoring tools — for organizations seeking an operationally transparent alternative to legacy NAS appliances. Qumulo environments are relevant in StorageMAP migration projects both as sources being migrated from and as targets for organizations adopting Qumulo as their next-generation file storage platform.

Qumulo is notable for its real-time analytics capability — unlike other NAS vendors that require scheduled scans for capacity reporting, Qumulo maintains live metrics as a first-class feature of its operating system. Qumulo’s cloud-native architecture (Cloud Q on AWS) enables seamless burst-to-cloud for on-premises workloads.

A media production company adopts Qumulo as its new NAS platform and uses StorageMAP to migrate 600 TB from its legacy Isilon cluster to Qumulo, combining StorageMAP’s migration capability with Qumulo’s native analytics for ongoing capacity management post-migration.

The Recovery Point Actual (RPA) is the real-time measurement of how much data would be lost if a failover were executed at a given moment — expressed as the time elapsed since the last successfully replicated state was committed to the secondary. Its purpose is to provide an objective, factual measure of the current protection level, enabling administrators to compare actual replication performance against the target RPO and detect degradation before it becomes a business risk. For planned failovers executed within a maintenance window, StorageMAP can drive the RPA to zero by completing a final synchronization round that closes the gap between primary and secondary before the cutover.

During routine operations, a StorageMAP dashboard widget shows that the RPA for a critical file server replication job is consistently 4 to 6 minutes against a 30-minute RPO. After a network upgrade that temporarily degrades WAN bandwidth, the RPA rises to 28 minutes, triggering a StorageMAP alert that prompts investigation before the RPO is breached.

Monitor RPA in real time as an early warning system — consistently rising RPA trends often signal infrastructure issues weeks before a full RPO breach occurs.

The Recovery Point Objective (RPO) is a business continuity metric that defines the maximum acceptable amount of data loss — expressed as a time interval — that an organization can tolerate in the event of a storage system failure. Its purpose is to establish a quantified service level for data protection that reflects the business cost of lost data, driving the required frequency and latency of the replication relationship needed to satisfy it. In StorageMAP, the RPO is configured per replication job; the system monitors the actual replication lag in real time and raises alerts when the measured gap approaches or exceeds the defined RPO threshold, giving administrators advance warning before an SLA violation occurs.

RPO is one of the two primary metrics of a BC/DR plan (alongside RTO). A zero RPO means no data loss is acceptable — requiring synchronous replication. An RPO of 4 hours means up to 4 hours of data change can be lost — achievable with periodic asynchronous replication.

A trading platform sets an RPO of 15 minutes for its order management NAS, driving a StorageMAP replication schedule that synchronises every 10 minutes with a safety margin. During an incident, the maximum data loss is confirmed to be 9 minutes — well within the 15-minute RPO commitment.

RAID (Redundant Array of Independent Disks) is a data storage technology that combines multiple physical disk drives into a single logical unit using striping, mirroring, or parity schemes to improve performance, capacity utilization, or fault tolerance. Its purpose is to protect storage environments against individual disk failures while improving read and/or write throughput, ensuring that the loss of a single drive does not result in data loss or service interruption. RAID is a foundational technology within the physical storage layer of NAS and SAN systems that StorageMAP manages, and is transparent to StorageMAP operations; its relevance to migration planning lies in understanding the effective usable capacity and rebuild overhead of source systems.

RAID was invented by Patterson, Gibson, and Katz at UC Berkeley in 1988 and has been the standard data protection mechanism for disk-based storage for over 35 years. While RAID remains universal in enterprise NAS and SAN systems, erasure coding — used in distributed object storage such as StorageGRID, Scality, and Cloudian — offers superior efficiency and multi-site protection for large-scale deployments.

During pre-migration planning, StorageMAP’s Discovery module reports that the source NAS has a drive failed and currently rebuilding. This finding triggers a decision to delay the migration until the rebuild completes, preventing the risk of data loss during a migration executed on a degraded array.

Replication is the ongoing, scheduled process of copying data from a primary storage location to a secondary location and keeping the two in continuous or near-continuous synchronization, so that the secondary can immediately substitute for the primary if the primary becomes unavailable. Unlike migration — which is a one-time transfer with a defined completion — replication is a persistent operational function that continuously protects live production data against failure and loss. StorageMAP manages Data Replication end-to-end, handling delta detection, incremental synchronization, RPO monitoring, failover orchestration, and failback for both NAS and object storage environments.

Data replication is a foundational component of Business Continuity and Disaster Recovery (BC/DR) strategies. Unlike backup — which creates point-in-time copies restored reactively — replication maintains a continuously updated secondary that can be activated proactively in near real time.

A global retailer replicates its NAS-based product catalogue (12 TB, updated hourly) from its primary data centre in Chicago to a secondary in Dallas, with a 30-minute RPO. When a power outage affects the Chicago DC, StorageMAP initiates a Failover in under 5 minutes and retail operations continue without noticeable interruption.

Replication RPO and RTO targets are defined in ISO 22301 Business Continuity Management and NIST SP 800-34 frameworks.

The StorageMAP REST API is the programmatic interface that allows external systems, custom scripts, and third-party integrations to manage and interact with StorageMAP using standard HTTP methods and JSON payloads. Its purpose is to enable automation of StorageMAP administration and to integrate StorageMAP capabilities into broader enterprise orchestration workflows — such as ITSM platforms, custom reporting dashboards, and automated provisioning pipelines — without requiring direct interaction with the web interface. The REST API exposes endpoints for the full lifecycle management of all major platform resources including jobs, file servers, object storage configurations, proxies, users, shares, exports, and replication groups.

A DevOps team integrates StorageMAP into their ServiceNow ITSM platform via the REST API, automatically creating a StorageMAP migration job whenever a storage refresh change ticket is approved. Job status updates are pushed back to the ticket via API as the migration progresses, giving the ITSM platform a real-time view of migration state without manual updates.

StorageMAP’s RESTful interface aligns with the OpenAPI specification, enabling straightforward integration with API gateway platforms such as MuleSoft, Kong, and AWS API Gateway.

Retrieval-Augmented Generation (RAG) is an AI architecture pattern that enhances the responses of a large language model by dynamically retrieving relevant information from an external knowledge source — typically a vector database of document embeddings — and providing that retrieved context to the model alongside the user’s query. Its purpose is to ground LLM responses in verified, up-to-date, organisation-specific information rather than relying solely on the knowledge encoded during model training, thereby reducing hallucination and enabling the model to reason over proprietary content it was never trained on. Building a RAG pipeline over enterprise unstructured data begins with discovering and cataloguing the source documents — a task for which StorageMAP provides the foundational data inventory.

RAG has become the dominant pattern for enterprise GenAI deployment because it avoids the cost and complexity of fine-tuning while allowing LLMs to operate on proprietary knowledge. The quality of a RAG system is directly dependent on the quality and freshness of the underlying document corpus, making strong data management — accurate discovery, classification, and access control of source documents — a prerequisite for reliable RAG-based applications.

A law firm builds a RAG-powered legal research assistant over its 20-year archive of case files and precedents stored on NAS. StorageMAP discovers and classifies all files, an embedding pipeline generates vectors for each document, and the vector database enables the RAG system to retrieve the top-k most relevant precedents for each attorney query — with the LLM synthesizing a grounded, cited response that the attorney can verify against the source documents.

Apply access control to the RAG retrieval layer — not just to the underlying documents. If a user should not have direct access to a document, they should not be able to retrieve its content indirectly through a RAG query. Align the RAG retrieval permissions with the data access governance policies enforced on the source storage, so that the AI layer does not become a bypass for existing access controls.

Reverse Replication is the reconfiguration of a StorageMAP replication job so that the data flow direction is inverted — with the previously secondary system becoming the new replication source and the previously primary system becoming the new target. Its purpose is to maintain continuous data protection after a Failover event, where the secondary is now serving production workloads and itself needs to be protected against failure during the recovery period. Reverse Replication is initiated as part of the post-failover operational workflow and remains in effect until the environment is stabilized and a Failback to the original primary can be safely executed.

After a 6-hour planned Failover during a primary site power maintenance window, Reverse Replication is configured so that data written to the secondary during the window (approximately 22 GB across 14,000 files) is continuously mirrored back to the recovering primary. Once the primary is validated, a Failback is executed and standard replication direction is restored — all without requiring a full re-baseline of either system.

Reverse replication is a standard capability in enterprise replication solutions such as NetApp SnapMirror, Dell EMC RecoverPoint, and IBM Spectrum Protect.

Scality provides two complementary S3-compatible on-premises object storage platforms: RING, a software-defined scale-out object store for petabyte-scale enterprise deployments with support for multi-site geo-distribution and compliance features; and ARTESCA, a lightweight Kubernetes-native object store for edge deployments and distributed environments where a full RING installation would be disproportionate. Their purpose is to give organizations S3-compatible private cloud object storage at any scale, from small edge deployments to multi-petabyte enterprise repositories, without requiring reliance on public cloud providers. Both Scality platforms are supported as object storage endpoints in StorageMAP O2O migration workflows, usable as sources or targets.

Industry context: Scality RING is the on-premises object storage choice for several major telecommunications providers, large media companies, and national research institutions that require petabyte-scale S3 storage under their own governance. RING’s erasure coding and geo-distribution capabilities provide comparable durability to hyperscaler object storage in on-premises deployments.

Example use case: a national broadcaster migrates 4 PB of archive content from a legacy tape-based system to Scality RING using StorageMAP, enabling instant S3-based access to archive content for their media asset management system while dramatically reducing retrieval costs compared to tape.

A Scan Root is a directory tree or object storage namespace registered with StorageMAP for indexing and ongoing analysis. Its purpose is to define the precise boundaries of the data that StorageMAP will monitor, measure, and make available for analytics and action. Once configured, StorageMAP scans the Scan Root on a defined schedule, builds a searchable index of all items within it, and makes that indexed data available for analyses, tagging, Storage Optimizer calculations, and workflow-driven data actions.

A media company configures ten Scan Roots — one per production NAS volume — and schedules daily scans. The resulting index reveals that 60% of capacity has not been accessed in over two years, a finding that directly informs a storage tiering business case.

Set Scan Root paths at the highest useful directory level to maximize analytical coverage, but exclude system directories and snapshot paths to avoid inflating item counts with non-user data.

A Security Identifier (SID) is a unique, variable-length binary value assigned by Windows and Active Directory to every user account, group account, and computer account within a domain or on a local system. Its purpose is to serve as the immutable, authoritative identity reference embedded in NTFS ACLs and Windows security descriptors, independent of the human-readable username that can change without affecting access control. Because SIDs are domain-specific — the same user will have a different SID in different Active Directory domains — SID translation is a critical requirement in any SMB migration that crosses a domain boundary. StorageMAP applies SID mapping files during SMB migrations to translate each source-domain SID in every ACL entry to its corresponding target-domain SID.

SIDs are defined in the Microsoft Windows Security Architecture and are the authoritative identity reference in Active Directory environments. They are unique per domain and are never reused — even after an account is deleted, its SID is permanently retired.

After a corporate acquisition, a 1.2 PB file server must be migrated from the acquired company’s domain to the acquiring company’s domain. StorageMAP applies a SID map generated from HR employee ID cross-referencing, correctly translating 22,000 user SIDs and 1,800 group SIDs across 4.5 million ACL entries — completed in the background during data transfer without extending the migration timeline.

A Server Cost Model is a configuration record within the Storage Optimizer that captures the financial and environmental specifications of a storage server — including its usable capacity, cost per terabyte per month, storage tier classification, and carbon emission profile. Its purpose is to provide the quantitative inputs necessary for simulation calculations to produce realistic, defensible estimates of storage cost. Server Cost Models are created for both existing managed servers and potential future platforms, allowing the Optimizer to compare current expenditure against projected costs after tiering and to model the carbon impact of data movement between different infrastructure options.

A storage architect builds cost models for three platforms — an on-premises NetApp AFF at $4.20/TB/month, a NetApp FAS at $1.80/TB/month, and AWS S3 Infrequent Access at $0.12/TB/month — and runs a simulation showing that tiering 800 TB of cold data would save $2.1M over three years.

Include a carbon emissions field in every cost model to support ESG reporting, which is increasingly required by enterprise procurement processes.

Server Message Block (SMB) is the network file-sharing protocol used by Windows and Windows-compatible systems to access files, directories, printers, and named pipes over a TCP/IP network, operating over TCP port 445 with a rich feature set including authenticated access, NTFS ACL enforcement, file locking, opportunistic locking, DFS namespace integration, and — in SMB 3.x — transparent failover, scale-out, and transport encryption. Its purpose is to provide seamless, transparent file access for Windows clients and to serve as the standard protocol for enterprise Windows file server environments. StorageMAP uses SMB to access Windows-protocol file servers during scan and migration operations, and configures SMB-specific options — including ACL handling, SACL copying, and DFS path tracking — as part of each migration job’s settings.

SMB was originally developed by IBM in 1983 and has been continuously improved through SMB 2.0 (Windows Vista), SMB 2.1 (Windows 7), and SMB 3.0/3.1.1 (Windows 8+). SMB 3.x adds end-to-end encryption, multichannel (multiple TCP connections for bandwidth aggregation), and transparent failover.

A StorageMAP migration targets FSx for Windows File Server, which requires SMB 3.x with Kerberos authentication. The migration job is configured with SMB 3.1.1 and domain credentials, achieving 600 MB/s throughput using SMB multichannel across a 25 GbE link.

Shares and Exports Management is the StorageMAP capability that automates the discovery, recreation, and validation of SMB shares and NFS exports on the target file server as part of the migration workflow. Its purpose is to ensure that when Switchover occurs, the target presents exactly the same access paths, share names, export configurations, and protocol options that users and applications expect, without requiring manual reconfiguration by an administrator. StorageMAP discovers share and export configurations on the source, replicates them on the target during the migration preparation phase, validates them during Dry Run, and activates them at the point of Switchover.

A Windows file server with 340 SMB shares is being migrated to FSx for Windows File Server on AWS. StorageMAP discovers all 340 share definitions, recreates them on the FSx target with identical names, permissions, and path mappings, and validates them during a dry run — a process that would take an experienced administrator several days to perform manually.

Automating share and export recreation eliminates the most error-prone manual step of a NAS migration and ensures that discrepancies are caught before Switchover rather than discovered by end users after.

A SID Map is a structured mapping file uploaded to StorageMAP that defines the correspondence between Windows Security Identifiers (SIDs) from the source Active Directory domain and their corresponding SIDs on the target domain. Its purpose is to ensure that NTFS ACLs on migrated files and directories correctly reference the target-domain identities of the same users and groups, preserving all access control permissions faithfully across a domain boundary. SID Maps are required for any SMB migration where source and target systems belong to different Active Directory domains — including cross-organization migrations, domain consolidations, and on-premises-to-cloud migrations that involve a new identity environment on the target.

During a merger integration, the IT team generates a SID map by exporting both domain’s user lists and cross-referencing by email address or employee ID. The resulting CSV is uploaded to StorageMAP before the migration begins, ensuring that all 2.4 million ACL entries on the source are correctly translated to the target domain’s SIDs.

Validate SID maps against a representative sample of files using a dry run before committing to a full migration, as unmatched SIDs result in unknown account ACL entries on the target that can silently deny legitimate user access.

A Small Language Model (SLM) is a language model with significantly fewer parameters than a large language model — typically ranging from tens of millions to a few billion parameters — that is designed to be deployed efficiently on constrained hardware such as edge devices, laptops, or standard enterprise servers without requiring GPU clusters. Its purpose is to deliver capable language understanding and generation for specific, well-defined tasks in environments where the computational cost of a full LLM is prohibitive. Examples include Microsoft Phi, Google Gemma, and Meta LLaMA variants optimised for resource-constrained inferencing. SLMs are increasingly deployed for on-premises AI workloads where data sovereignty or latency requirements preclude cloud-based LLM APIs.

The SLM category has grown rapidly as enterprises seek AI capabilities without the cost, latency, and data-residency concerns of cloud LLM APIs. Microsoft’s Phi-3 series and Meta’s LLaMA 3.2 have demonstrated that models under 10 billion parameters can match or exceed larger models on targeted tasks when properly fine-tuned — accelerating on-premises AI deployment across regulated industries.

A government agency deploys an SLM on-premises to classify and summarize documents discovered by StorageMAP across its NAS estate, without transmitting sensitive content to external cloud services. The SLM processes document metadata and content extracted from the StorageMAP catalog to generate governance-ready summaries for the agency’s records management team.

SLMs enable organizations to bring AI capabilities to sensitive data that cannot leave the enterprise perimeter, aligning with data sovereignty requirements, air-gapped environments, and the principle of data minimization — processing data in place rather than transmitting it to external inference endpoints.

A snapshot is a point-in-time, read-only capture of a file system or volume’s state, created near-instantaneously by recording a metadata pointer to the current state of all data blocks rather than physically copying them. Its purpose is to provide an immediately available recovery point from which the storage system can restore data to a known-good state after accidental deletion, corruption, or a failed change, without the time and capacity overhead of a full backup copy. Snapshots are a native capability of most enterprise NAS platforms and are relevant to StorageMAP migration planning both for establishing a consistent source baseline at migration initiation and for providing rollback capability during the migration window.

Snapshot technology was pioneered by NetApp’s WAFL (Write Anywhere File Layout) file system in the early 1990s and is now a standard feature of every enterprise NAS and SAN platform. Most enterprise environments maintain 24 to 72 hours of hourly snapshots plus weekly snapshots for 4 to 8 weeks.

A StorageMAP migration begins with a source snapshot as the initial baseline, ensuring that all incremental sync rounds compare against a consistent baseline state. This prevents false positives in the change detection logic caused by application writes occurring during the initial bulk copy scan.

A Storage Area Network (SAN) is a dedicated, high-speed network providing servers with block-level storage access, presenting remote storage to the operating system as locally attached disk devices that the server formats and manages with its own file system. Its purpose is to deliver the high throughput and deterministic low latency required by performance-sensitive workloads such as relational databases, virtual machine hypervisors, and transactional processing systems that need block-level I/O control. SANs use Fibre Channel or iSCSI protocols and are distinct from the NAS and object storage systems that StorageMAP directly manages; however, they are commonly co-deployed in the same data center environments and are relevant context for understanding the full storage infrastructure landscape during migration planning.

SANs remain the dominant storage technology for mission-critical block workloads — relational databases, ERP systems, virtual machine boot volumes, and high-frequency trading platforms. The global SAN market is estimated at $18 billion annually. While StorageMAP does not directly manage SAN environments, understanding SAN topology is important in storage migration projects where NAS data may be co-located with SAN workloads on shared infrastructure.

Storage capacity is the total amount of data that a storage system can hold, typically expressed in terabytes (TB) or petabytes (PB), representing the foundational resource constraint around which all storage management, planning, and procurement decisions revolve. Its purpose as a metric is to define the boundaries within which a storage environment must operate, driving decisions about when to acquire additional hardware, when to tier or delete data to reclaim space, and how to allocate existing capacity across competing workloads. StorageMAP’s scan analytics provide detailed visibility into capacity consumption by server, directory, owner, file type, and data age, enabling evidence-based capacity management that goes beyond simple free-space monitoring.

IDC projects that global data creation will reach 175 zettabytes by 2025, with enterprise storage consumption doubling every 2 to 3 years. Uncontrolled data growth is the primary driver of storage cost escalation — organizations that do not actively manage data lifecycle routinely experience 20 to 30% annual capacity growth even with stable headcounts.

A media organization uses StorageMAP capacity analytics to identify that 45% of its 6 PB NAS estate contains data older than 3 years, enabling a tiering programme that reduces primary NAS growth from 35% to 12% annually — deferring a $4M hardware refresh by 3 years.

Storage class is a metadata attribute assigned to an individual object in a cloud or compatible object storage system that governs its availability tier, retrieval latency, redundancy level, and per-GB cost — allowing a single storage service to offer multiple performance and price trade-offs under one API. Its purpose is to enable cost optimization at the object level by matching the access requirements of each object — how frequently it will be read, how quickly it must be retrievable — to the most economically appropriate storage tier. StorageMAP reads storage class as part of object metadata during scans and preserves or remaps storage classes during O2O migrations based on configuration, allowing organizations to change tiering strategies at the point of migration without requiring post-migration reclassification.

S3 storage class architecture is the most widely adopted tiering model in cloud storage, with AWS alone offering eight storage classes ranging from S3 Express One Zone (sub-millisecond latency) to S3 Glacier Deep Archive ($0.00099/GB/month, 12-hour retrieval). Azure and GCS offer equivalent tiering models.

During an O2O migration from on-premises StorageGRID to AWS S3, StorageMAP remaps storage classes based on object age — objects modified in the last 2 years go to S3 Standard, 2 to 5 years to S3 Infrequent Access, and over 5 years directly into S3 Glacier — implementing a three-tier cloud storage strategy as a direct outcome of the migration.

The Storage Optimizer is a StorageMAP module that enables data temperature analysis and cost modeling for unstructured storage environments. Its purpose is to help organizations identify cold or underutilized data and quantify — in financial and environmental terms — the savings achievable by relocating it to more cost-effective storage tiers. It is used by storage architects and financial stakeholders to define cold data conditions, build server cost models, and run simulations that project the total cost and carbon impact of tiering decisions before any data movement is committed to.

A university runs the Storage Optimizer against its 2 PB research NAS estate and discovers that 1.4 PB qualifies as cold under a not-accessed-in-18-months policy. The simulation shows that moving cold data to an on-premises S3-compatible object store would reduce storage costs by $340,000 annually and cut the estate’s carbon footprint by 28%.

Industry standard alignment: the Optimizer implements the principles of HSM (Hierarchical Storage Management) as defined in the SNIA Dictionary, modernised for cloud and object storage economics.

A Storage Simulation is a what-if scenario executed within the Storage Optimizer that projects the financial and environmental impact of relocating cold data from its current storage tier to a designated lower-cost alternative over a user-defined time horizon. Its purpose is to quantify the business case for data tiering before any commitment to infrastructure change or data movement, turning abstract policy recommendations into concrete, dollar-denominated projections grounded in real scan data and actual server cost models. Administrators run multiple simulations varying cold data conditions, target tiers, or simulation periods to identify the highest-value optimization scenario before initiating action.

A global law firm runs three simulations — one for a 1-year cold data threshold, one for 2 years, and one for 3 years — and compares the resulting cost savings, capacity freed, and carbon reduction for each scenario. The 2-year threshold emerges as the optimal balance between business risk and financial benefit, providing a 45% storage cost reduction.

The simulation capability allows organizations to test multiple policies against real scan data before committing resources, reducing the risk of policy decisions that are either too aggressive or too conservative.

A Storage Tier is a classification assigned to a storage server or storage service that describes its position in a hierarchy defined by performance, availability, and cost — ranging from high-performance all-flash primary storage at the top to low-cost, high-latency archive storage at the bottom. Its purpose is to provide a structured framework for data placement decisions that align the cost of storing data with the business value and access frequency of that data. In StorageMAP, Storage Tiers are assigned within Server Cost Models and are used by the Optimizer to identify valid relocation targets for cold data and to calculate the per-tier cost differential that drives simulation results.

The SNIA Cloud Storage Reference Model defines multiple storage tiers with different performance and cost trade-offs, ranging from Performance (NVMe flash), Capacity (hybrid or HDD NAS), and Archive (object or tape).

A media company defines four tiers — Production at $8/TB/month, Nearline at $1.50/TB/month, Archive at $0.40/TB/month, and Cloud Archive at $0.004/TB/month — and uses StorageMAP to automate movement between tiers based on access age.

StorageMAP is Datadobi’s vendor- and cloud-neutral data management platform for unstructured data. Its purpose is to give enterprises a single, unified system for visualizing, organizing, and acting on their entire unstructured data estate — whether on-premises, in the cloud, or across hybrid environments. StorageMAP is used by storage administrators and data managers to scan file systems and object storage, run analytics, enforce data policies, and execute migrations, replications, and data lifecycle actions from one central interface.

A financial services firm with 12 petabytes spread across seven NAS vendors uses StorageMAP to produce a unified capacity and age report in hours, identify 4 PB of cold data, and migrate it to cloud object storage — all from a single interface.

StorageMAP supports POSIX, NTFS ACL, SMB 3.x, NFSv3/v4, and S3 protocols, ensuring compatibility with the full spectrum of enterprise storage.

Eliminating point-in-time manual audits reduces storage management overhead by up to 70% while accelerating data governance and compliance reporting.

StorageMAP ASP Migrate Edition is a purpose-built edition of the StorageMAP platform focused on large-scale data migration projects, offered through Datadobi’s service provider program. It is designed to support managed service providers and enterprise customers who need structured, auditable migration workflows without requiring the full analytics and optimization feature set of the broader platform. It is used to execute NAS-to-NAS migrations over SMB and NFS protocols, as well as Object-to-Object migrations using the S3 protocol, with features such as Discovery, File System Assessment, and Chain of Custody built specifically for the migration lifecycle.

A system integrator delivers a 500 TB NAS consolidation project for a healthcare client, using ASP Migrate Edition to produce a Discovery report, execute NAS-to-NAS migrations over NFS and SMB simultaneously, generate a Chain of Custody record for HIPAA compliance, and hand the client a signed completion report.

The edition’s built-in migration orchestration dramatically reduces project risk by making every step auditable and repeatable, which is critical when operating under fixed-price service contracts.

StorageMAP Core is the central software component of the StorageMAP platform, responsible for orchestrating all data operations, user interfaces, and configuration management across the deployment. Its purpose is to serve as the installation and configuration foundation from which all StorageMAP capabilities are enabled, acting as the control plane that coordinates proxy workers, manages the central scan database, and presents the web-based interface to administrators. StorageMAP Core must be installed and licensed before any other component or module can be configured.

Best practice: Core should be deployed on dedicated, high-availability infrastructure with regular database backups configured through Global Settings. In large-scale deployments, Core can be fronted by a load balancer for web interface resilience.

Industry context: the centralised control-plane model is standard in enterprise data management platforms such as NetApp BlueXP, IBM Spectrum Control, and Dell EMC Unisphere, making the Core concept immediately familiar to experienced storage administrators.

A Switchover is the final phase of a StorageMAP migration in which the system performs a last incremental scan of the source, transfers any remaining changed data to the target, and confirms that source and target are fully synchronized before the source is decommissioned. Its purpose is to complete the migration with the minimum possible data gap and the shortest maintenance window, by deferring the final delta copy to a point where all prior synchronization rounds have already transferred the bulk of the data. The Switchover is the trigger for administrators to redirect DNS records, DFS namespace links, or client mount points from the source to the new target system.

Minimizing the switchover window is the primary SLA pressure in enterprise storage migrations. Most organizations can tolerate maintenance windows of 1 to 4 hours for non-critical systems and 15 to 30 minutes for business-critical file servers.

After six weeks of nightly incremental synchronization rounds, a StorageMAP migration reaches its final Switchover with a data delta of only 12 GB — resolved in under 90 seconds — against a 400 TB dataset, well within the agreed 2-hour maintenance window.

Schedule Switchover during the lowest-traffic period and pre-notify all affected users at least 48 hours in advance.

A symbolic link (symlink) is a special file type in Unix and Linux file systems that stores a text string pointing to the path of another file or directory, causing the operating system to transparently redirect any access to the symlink to its referenced target. Its purpose is to provide flexible aliasing — allowing a single file or directory to appear accessible from multiple locations in the namespace, or decoupling application path references from physical data locations so that data can be moved without breaking application access. Symlinks are a distinct item type in file system scans, reported separately in StorageMAP’s DQL output, and their handling during migrations — whether the link text, the link target, or both are copied — requires explicit planning.

Symlinks are pervasive in Unix/Linux file system administration — used by package managers, application deployments, and configuration management systems. Symlinks that reference paths outside the migrated Scan Root are a common source of application issues after NAS migrations if not identified during planning.

A pre-migration Discovery scan of a 300 TB research NAS identifies 14,000 symlinks, of which 3,400 point to paths on a different NAS server not included in the migration scope. These dangling symlinks are flagged in the Discovery report, enabling the project team to decide whether to update the target paths or migrate the referenced NAS as well.

A Tag is a user-defined label in StorageMAP that is applied to a dataset or directory tree to classify data according to business context — such as department ownership, data role, retention policy, or risk profile. Its purpose is to enrich raw file system metadata with organizational meaning that the file system itself does not store, enabling governance, reporting, and policy enforcement at scale. Tags are displayed in StorageMAP dashboards alongside capacity and item count metrics, and can be used to drive bulk data actions or workflow policies across all data bearing a specific tag.

As part of a data governance initiative, the storage team tags all directories under the Finance department’s path with the tags Cost-Center: Finance, Retention: 7yr, and Data-Classification: Confidential. These tags immediately surface in Dashboard widgets, enabling the CISO to report on Confidential data footprint without any additional manual inventory.

Tagging approaches mirror best practices in cloud resource management (AWS tags, Azure labels) and are foundational to implementing GDPR data subject access request workflows.

TCP/IP (Transmission Control Protocol/Internet Protocol) is the foundational communication protocol suite that underpins all modern networking, providing the addressing and routing (IP) and reliable, ordered data delivery (TCP) over which all higher-level application protocols — including SMB, NFS, S3, LDAP, and HTTPS — operate. Its purpose is to define the universal, interoperable transport layer that allows any two networked devices to communicate regardless of their physical location, hardware, or operating system. In StorageMAP deployments, TCP/IP is the transport layer for every data operation and management communication; network design, IP addressing, routing, and security at the TCP/IP layer directly determine the reachability and performance of all StorageMAP workflows.

TCP/IP was standardized in 1981 (RFC 793 for TCP, RFC 791 for IP) and is the foundation of the internet and virtually all enterprise networking. Modern data centres use 10 GbE, 25 GbE, 100 GbE, and 400 GbE Ethernet as the physical layer for TCP/IP.

A StorageMAP migration running over a 10 GbE Ethernet link between source and target achieves 800 MB/s sustained throughput (80% of link capacity) with Throttling configured at the remaining 20% reserved for production traffic — completing a 200 TB migration in approximately 70 hours.

Throttling is a configurable bandwidth and resource management mechanism in StorageMAP that limits the rate at which Proxy-executed operations — migrations, replications, scans, and data moves — consume network bandwidth and storage I/O. Its purpose is to ensure that StorageMAP’s background data management activities do not compete with production workloads for network or storage resources during business-critical periods, while still making full use of available infrastructure during off-peak windows when capacity can be dedicated to data movement. Throttling schedules are configured per Proxy and define named bandwidth policies — such as ‘full speed overnight’ and ‘restricted during business hours’ — that are applied automatically based on time of day and day of week.

Example use case: a 10 GbE link shared between a production file server and a migration Proxy is protected by a Throttling schedule that limits the Proxy to 2 Gbps during 8 AM to 6 PM weekdays and 8 Gbps during nights and weekends. This ensures migration never consumes more than 20% of production bandwidth during business hours while still completing a 400 TB migration within a 3-week window. Industry

best practice: always baseline production network utilisation before configuring throttle limits, as setting limits without baseline data can result in either under-throttling (impacting users) or over-throttling (unacceptably extending migration timelines).

Transport Layer Security (TLS) is a cryptographic protocol that establishes an authenticated, encrypted channel between two communicating parties over a TCP/IP connection, ensuring that data exchanged cannot be read or modified by third parties with access to the network path between them. Its purpose is to protect network communications — including web traffic, API calls, and storage protocol connections — from interception, eavesdropping, and tampering, replacing the earlier and insecure SSL protocol. StorageMAP uses TLS to protect all web interface traffic, REST API communications, S3 HTTPS connections to object storage endpoints, and LDAPS connections to directory servers, and TLS certificate validity and trust configuration must be correctly maintained for all StorageMAP HTTPS connections to function.

TLS 1.2 (RFC 5246, 2008) and TLS 1.3 (RFC 8446, 2018) are the current standards. TLS 1.0 and 1.1 are deprecated and prohibited by PCI-DSS v4.0 and NIST 800-52 Rev 2. TLS 1.3 reduces handshake latency by 50% compared to TLS 1.2, which is significant for high-frequency S3 API calls in O2O migrations.

A PCI-DSS scoped StorageMAP deployment is verified by the QSA to use TLS 1.2+ for all management and S3 API traffic, satisfying PCI-DSS Requirement 6.5.4 (encryption of data in transit) as part of the organization’s annual PCI compliance assessment.

UID (User Identifier) and GID (Group Identifier) are the numeric values used by Unix and Linux operating systems to represent the owner and owning group of a file in the inode’s permission metadata. Their purpose is to provide the operating system with compact, efficient numeric references to user and group identities that are evaluated alongside POSIX permission bits to determine file access rights. Because UIDs and GIDs are numeric integers that carry meaning only within the context of a specific system’s user database, the same UID on two different NAS systems does not necessarily refer to the same person. StorageMAP resolves this through UID/GID mapping files uploaded during NAS migration configuration, translating source numeric identifiers to their correct counterparts on the target system.

Industry context: UID/GID identity management in NFS environments typically relies on either LDAP-based centralised user databases or locally maintained /etc/passwd and /etc/group files. In legacy or loosely managed environments, UIDs and GIDs can drift between systems — making explicit UID/GID mapping files essential for accurate NFS migrations.

Example use case: a university migrating from an old research NAS to a modern Linux NFS server uses StorageMAP’s UID map to translate legacy UIDs to the correct LDAP-managed UIDs on the new system, preserving file ownership for 8,000 active research users.

Unstructured data is information that does not conform to a predefined schema or relational data model — encompassing documents, spreadsheets, presentations, images, video, audio, email, log files, code, and sensor outputs — and is stored as discrete files or objects whose internal organization is encoded in the content itself rather than in the storage system’s schema. Its purpose as a category is to describe the dominant form of enterprise data by volume, which typically represents 80-90% of total data storage and grows at a significantly faster rate than structured database data. Unstructured data is the exclusive focus of StorageMAP, which is purpose-built to provide visibility, governance, and lifecycle management across this class of storage at enterprise scale.

Gartner estimates that 80% of all enterprise data is unstructured and growing at 55 to 65% annually — far faster than structured data. Unstructured data management has become a top-5 CIO priority due to storage cost implications, regulatory governance requirements (GDPR, CCPA, HIPAA), and its emerging role as training data for AI/ML models.

A global pharmaceutical company uses StorageMAP to gain the first complete inventory of its 8 PB unstructured data estate across 47 NAS systems and 12 countries — a task that previously required 3 months of manual scripting per quarter now completed in 6 hours with automated daily updates.

In the context of artificial intelligence and machine learning, a Vector is a fixed-length numerical array that represents the semantic content or meaning of a piece of data — such as a word, sentence, image, or file — in a high-dimensional mathematical space. Its purpose is to encode information in a form that machine learning models can process and compare: data objects with similar meaning or characteristics are encoded as vectors that are geometrically close to one another, enabling similarity search, clustering, and retrieval operations. Vectors are the fundamental data structure underlying modern AI applications, and the storage and management of vector data at enterprise scale is an emerging challenge for unstructured data infrastructure.

The widespread adoption of transformer-based AI models (BERT, GPT, and their successors) has made vectors the lingua franca of enterprise AI. Every major AI platform — from OpenAI to Hugging Face — represents knowledge as vectors, and organizations are increasingly required to generate, store, and query vectors derived from their own proprietary data as part of RAG and semantic search implementations.

A legal services firm generates vectors from 10 million contract documents stored on NAS, using StorageMAP to identify and export the files to a processing pipeline that calls an embedding model. The resulting vectors are stored in a vector database and used to power a semantic contract search tool that retrieves relevant clauses by meaning rather than keyword.

A Vector DB (vector database) is a specialised data store designed to efficiently index, store, and query high-dimensional vector data — the numerical embeddings generated from documents, images, audio, and other unstructured content. Its purpose is to enable approximate nearest-neighbour (ANN) search at scale: given a query vector, the database rapidly identifies the stored vectors that are most semantically similar, making it the core retrieval engine for AI applications such as RAG, semantic search, and recommendation systems. As organisations generate embeddings from their unstructured data estates, vector databases become a critical new storage tier that must be provisioned, managed, and governed alongside traditional NAS and object storage.

Purpose-built vector databases — including Pinecone, Weaviate, Qdrant, Milvus, and pgvector (PostgreSQL extension) — have emerged as a distinct product category since 2022, driven by the AI application boom. Traditional relational and document databases are adding vector search capabilities, but purpose-built vector databases typically offer superior performance and scalability for high-dimensional ANN workloads at petabyte scale.

A financial services firm uses StorageMAP to identify and export 2 million analyst reports from its NAS estate, generates embeddings from the report text, and loads the vectors into a Pinecone vector database. The vector database powers an internal research assistant that retrieves the most relevant historical reports in response to natural language queries from portfolio managers.

A version ID is a unique identifier automatically assigned by an object storage system to each successive write of an object key when bucket versioning is enabled, preserving the full history of an object as a series of individually addressable versions rather than overwriting each prior state. Its purpose is to protect against accidental deletion or overwrite by retaining all previous versions of every object, making any earlier state recoverable by referencing its specific version ID. When StorageMAP migrates versioned buckets, version handling — whether all versions or only the current version are migrated — must be explicitly configured to ensure the target carries the required version history to meet recovery and compliance requirements.

S3 object versioning is enabled by default on many compliance-grade object storage deployments and is required for S3 Object Lock (WORM) configurations. AWS charges for all stored versions at the same rate as the current version, so versioned buckets often consume significantly more storage than their apparent object count suggests.

A StorageMAP O2O migration of a versioned S3 bucket discovers that 500,000 current objects are accompanied by 12 million total object versions — consuming 24x more storage than the current-version-only view suggests. The migration is configured to migrate only the current version plus versions from the last 12 months, reducing migration scope and target storage requirement by 85% while satisfying the organization’s 12-month recovery point policy.

A VLAN (Virtual Local Area Network) is a logical network segment created by configuring Ethernet switches to group a set of ports into an isolated broadcast domain, separating network traffic by function, security requirement, or organizational boundary without requiring separate physical network infrastructure. Its purpose is to allow a single physical network to carry multiple logically separated traffic types — such as storage traffic, management traffic, and user data traffic — with the isolation benefits of separate networks but the operational simplicity of shared hardware. In StorageMAP deployments, dedicated storage VLANs are commonly used to provide predictable, uncontested bandwidth for migration and replication data traffic, isolated from the general user and management network.

VLANs are defined in IEEE 802.1Q (1998) and are universally implemented in enterprise switches. QoS markings via IEEE 802.1p can be applied to storage VLANs to prioritize storage traffic over lower-priority workloads on shared physical links.

A StorageMAP deployment uses a dedicated storage VLAN for all Proxy-to-NAS traffic, a separate management VLAN for StorageMAP Core web interface access, and the production user VLAN for end-user NAS access — providing three-way isolation that prevents migration traffic from impacting user or management access.

Warm data is data accessed occasionally — typically monthly or quarterly — that does not justify the expense of primary flash storage but is needed frequently enough that deep cold archive with multi-hour retrieval would cause unacceptable delays. Its purpose as a classification is to identify a middle tier of data that is best served by mid-range capacity storage — such as hybrid disk/SSD NAS or cloud infrequent-access storage classes like AWS S3 Infrequent Access or Azure Cool — that offers meaningful cost savings over all-flash primary storage while maintaining acceptable response times for the access patterns it serves.

A professional services firm classifies its data into three temperature bands using a StorageMAP Classifier: Hot (accessed in 90 days, 18% of estate), Warm (91 to 365 days, 22%), and Cold (over 365 days, 60%). The Warm tier is targeted for migration to a capacity-optimised hybrid NAS tier ($1.80/TB/month) rather than the archive tier, preserving reasonable access times for quarterly financial reports and project archives that are occasionally still needed.

Correctly identifying the warm tier prevents the business disruption that occurs when data is moved to archive tiers with slow retrieval times before users are truly done with it.

Wasabi Technologies is a cloud object storage provider offering fully S3-compatible storage at a single flat per-terabyte monthly price with no egress fees, no API request charges, and no minimum storage duration fees, designed as a cost-predictable alternative to the variable pricing models of the major hyperscalers. Its purpose is to lower the cost and simplify the billing for cloud object storage workloads — particularly backup, archiving, media, and secondary storage — where the unpredictable egress and per-request fees of AWS S3 or Azure Blob represent a significant and hard-to-forecast cost. Wasabi is a common target in StorageMAP O2O migration projects, particularly for organizations consolidating backup or media archive data into low-cost cloud object storage under a predictable spend model.

Industry context: Wasabi’s flat-rate pricing ($7/TB/month with no egress fees) is approximately 80% cheaper than AWS S3 Standard with typical egress for datasets with high egress volume, making it particularly attractive for backup and media delivery use cases.

Example use case: a video production company uses StorageMAP to migrate 1 PB of completed project archives from an expensive on-premises primary NAS to Wasabi, reducing annual storage costs from $180,000 to $8,400 — a 95% reduction — while maintaining S3-compatible access for all downstream distribution workflows.

A Workflow is an automated, policy-driven sequence of analytics and data action steps in StorageMAP that executes on a configurable schedule without requiring manual intervention after initial setup and publication. Its purpose is to operationalize repeating data lifecycle management policies — such as scanning storage weekly, identifying files that have not been accessed in two years, and moving them to archive — as fully automated background processes that run consistently without operator effort. Once published with a schedule, a Workflow chains together scan operations, analysis steps with filters and classifiers, optional Approval Gates, and data actions, running each step in sequence according to its defined policy.

A financial services firm implements a Quarterly Archive Workflow that scans all 12 file servers, identifies files not accessed in 1,095 days, presents results for Compliance Officer approval, and moves approved datasets to an archive tier. The workflow runs automatically every quarter without manual intervention beyond the approval step.

Automated data lifecycle workflows directly support compliance with SEC Rule 17a-4, GDPR Article 5 (data minimisation), and ISO 27001 Annex A.8.2 (information classification) requirements.

A Workflow Schedule is the timing configuration that defines when and how frequently a published StorageMAP Workflow executes automatically. Its purpose is to align automated data lifecycle operations with business rhythms and capacity management cycles — for example, running a cold data archiving workflow at the end of each quarter, or generating a storage utilization report on the first day of each month. Schedules are defined using cron-style expressions for precise control over execution frequency, and once a Workflow is published with a schedule, it runs at the specified cadence without any further manual trigger.

An operations team configures four Workflow Schedules: a nightly scan at 2 AM, a weekly cold-data report every Monday at 6 AM, a monthly capacity trend Dashboard refresh on the 1st of each month, and a quarterly archive action every 90 days. Once configured, the entire data management lifecycle runs without operator intervention.

Align Workflow Schedules with the organization’s Change Management calendar — avoid running data movement workflows during freeze periods such as quarter-end closes or major application releases.

A WORM Migration is a StorageMAP migration that transfers data from Write Once Read Many (WORM) storage systems, where files are immutable after being written and are subject to legally mandated retention locks that prevent modification or deletion until a defined expiry date. Its purpose is to move compliance-protected data to a new storage platform without compromising the immutability attributes and retention periods that define the legal posture of that data. StorageMAP handles WORM migrations with specialized logic to preserve retention lock periods, commitment dates, and immutability flags on the target, ensuring that the migrated data remains compliant with the same regulatory obligations it was subject to on the source.

WORM storage compliance requirements are mandated by regulations including SEC Rule 17a-4 (financial), CFTC Rule 1.31 (commodities), HIPAA (healthcare), and Sarbanes-Oxley Section 802 (corporate records).

A broker-dealer migrates 15 years of trade records from a legacy EMC Centera WORM platform to NetApp StorageGRID using StorageMAP’s WORM migration capability, preserving all retention lock expiry dates to the day and maintaining SEC Rule 17a-4 compliance without a single gap in the audit record.

Write Once Read Many (WORM) is a storage immutability model in which data, once written, cannot be modified or deleted until a defined retention period has expired — enforced by the storage system’s firmware or software regardless of any instruction from an operating system or application. Its purpose is to satisfy regulatory and legal requirements mandating that specific records be preserved in their original, unaltered form for defined periods — including SEC Rule 17a-4 for financial records, HIPAA for healthcare data, and FDA 21 CFR Part 11 for regulated life sciences data. WORM capabilities are delivered through technologies such as NetApp SnapLock, Dell EMC DataDomain Retention Lock, S3 Object Lock, and Azure Blob immutable storage. StorageMAP handles WORM data with specialized migration logic that preserves retention lock attributes on the target.

WORM compliance is mandatory in financial services (SEC 17a-4, CFTC 1.31, MiFID II), healthcare (HIPAA, 21 CFR Part 11), and government (NARA regulations) environments. The global WORM storage market is estimated at $8 billion annually. S3 Object Lock has emerged as the standard API for WORM enforcement in cloud and S3-compatible on-premises platforms.

A CFTC-regulated commodities broker uses StorageMAP’s WORM migration capability to migrate 12 years of trading communications from a legacy EMC Centera platform to a new Cloudian HyperStore S3 Object Lock implementation, preserving all retention lock expiry dates to maintain CFTC Rule 1.31 compliance without a single-day gap in the regulatory record.