About Cloud Sync
Cloud Sync is designed as a paid web service that keeps selected SharePoint documents available in a separate Nextcloud environment, so employees can continue working during a SharePoint or broader Microsoft outage.
The use case
A company uses SharePoint for daily document work. Its administrator connects Microsoft 365 and a separate Nextcloud environment, then selects the document libraries and folders needed for continuity.
Cloud Sync keeps the selected files and supported access rights up to date. During normal operation employees work in SharePoint; their Nextcloud copy is read-only.
During an outage the customer administrator manually activates failover. Synchronization stops before the agreed editing rights are enabled in Nextcloud. Employees sign in independently of Microsoft and continue working.
After SharePoint recovers, the administrator reviews changes and conflicts, manually returns the required changes to SharePoint and explicitly confirms recovery before synchronization resumes.
Customers and responsibilities
The service will support multiple paying customers with strictly separated administrators, connections, settings, data and reports. Customer administrators can access only their own environment.
The service administrator creates customers and invites their administrators. Public self-registration is outside the first release. Service administration covers onboarding, subscriptions and technical support; document access is not a default entitlement.
Each customer connects a separate existing Nextcloud environment. The customer, service provider or hosting partner may operate it. Onboarding records responsibility for updates, capacity and availability. Automatically creating and maintaining Nextcloud installations is outside the first release.
One synchronization target and an optional root folder
Decision: configure one Nextcloud synchronization target per customer. Separate test and production targets are not part of the approved Cloud Sync customer configuration. Connection checks and the guided failover exercise use this same target, with clearly separated test documents.
An empty root-folder setting means no additional enclosing folder: library Team folders appear at the top level, for example Finance and HR. A root-folder setting of SharePoint groups those managed library folders under SharePoint/Finance and SharePoint/HR. Selected descendants retain their source hierarchy within each library.
Reason: customers configure one actual continuity destination, reducing setup effort and the risk of confusing test and live destinations. Optional grouping keeps synchronized libraries together while preserving separate, organization-managed library storage.
The root folder describes the visible destination grouping, not the Nextcloud server filesystem root and not the synchronization account's personal storage. Validate that the selected Nextcloud/app version supports the requested managed mount layout and that every authorized user can see and access it correctly. Do not silently replace managed library folders with personal folders or widen access to make the grouping work.
Implementation status: the local service configures one target and an optional root, rejects library-name collisions and checks managed mount properties read-only. The non-mutating conversion helper requires an explicit choice when multiple legacy targets exist; no automatic import is enabled. Effective access and grouped-root compatibility still require validation on the customer's Nextcloud version. The separate legacy migration command retains historical settings and evidence.
A short setup with useful defaults
Setup follows Connect > Select scope > Check and start. Account and group mappings are suggested automatically; only missing information and permission exceptions require attention. Advanced settings are shown only when needed.
In the local Connections screen, Check connections saves the entered settings and starts a read-only check without requiring a separate save. The form retains entered values and later edits while its inline result updates. Saved secrets are kept securely and are never returned to a newly opened page; blank secret fields retain their saved values. Connections has a single Check connections action at the bottom of its form; a separate save button is unnecessary because checking also saves. Discover libraries is at the top of Synchronization scope, keeping library discovery beside scope selection. Scope groups libraries into separate SharePoint site blocks and shows an indented folder tree. The Scope column contains only library and folder names. A fourth Target folder column places editable library destination names beside their sources, defaulting to the source names and retaining saved edits. This keeps source selection and destination naming together. Subfolders retain their names and hierarchy inside each managed library folder. Select a library or folder to include all descendants automatically; clear the parent to choose individual folders. Scope selections and target folder names save automatically, with compact save feedback and no separate save button. Pending saves finish before scanning or navigation; save failures remain visible. Saved scope contains selected roots so new descendants remain included. This reuses the familiar migration selection interaction without manual folder-path entry. It uses the saved connections and the existing read-only background check, with one inline status; results and audit evidence remain automatic.
Scan selected scope saves the current selection and starts a durable read-only SharePoint sizing scan in the background. Files and Size show cumulative counts and decimal sizes (kB, MB, GB and TB) for selected descendants per row; unselected locations are not scanned. The selected total counts each file once, even when parent and child selections overlap. Results show the scan time and are indicative observations, not a transactionally frozen source snapshot, permission approval or synchronization evidence. Empty scanned folders show zero; unscanned, stale or incomplete results never imply zero. Changing the source settings or scope requires a new scan. Progress stays inline beside the scan button; browser edits are retained on completion. Interrupted scans restart safely. Results and audit events are saved automatically; the last 50 scan outcomes are included in the existing optional audit export. No assessment approval or separate report-generation step is added. The initial synchronization starts after the necessary connection and scope checks. A failover exercise does not block configuration or this initial synchronization.
A customer is marked failover-ready only after a successful initial synchronization and a guided failover exercise. The exercise checks file verification, independent sign-in, read and edit permissions, collaborative editing and recovery using test documents. Results and blockers are recorded automatically.
What is synchronized
The customer explicitly selects SharePoint sites, document libraries and folders. Current files and folder structure are included, with access governed by the agreed permission model.
New files and subfolders inside selected locations are included automatically when their rights can be processed correctly. New sites and libraries require explicit selection.
Existing SharePoint version history, lists, pages, workflows and custom business metadata are outside the first release. File creation and modification timestamps, source author/editor information and synchronization timestamps are explicitly included as basic continuity information. Recovery retention begins with content captured by Cloud Sync; historical SharePoint versions are not imported.
Storage ownership: decision and rationale
Decision: SharePoint document libraries, folders and files must use centrally managed Nextcloud Team folders / Group folders storage, not personal folders shared by an employee or the synchronization account. The organization controls the storage independently of individual account lifecycles.
Reason: shared company documents must remain available when an employee leaves or an account is deleted. A service account may access the destination for transfer, but its personal storage must not become the destination or the ownership model.
Access is granted through the supported group permission model. Any direct-user permissions need explicit supported mapping and must not turn the folder into a personal share. Use one managed Team folder per selected SharePoint document library, preserving selected subfolders as nested folders inside it. Every descendant remains organization-managed. When only part of a library is selected, synchronize only that part. A separate managed root for a subfolder requires an explicit administrative reason, such as an independent storage quota.
If personal OneDrive content is included in a future scope, personal Nextcloud storage may be appropriate for that content. This conditional exception does not add OneDrive to the currently approved release scope.
Folder-layout rationale: the library is a clear management and access boundary. Keeping its descendants nested preserves the familiar source hierarchy and avoids unnecessary storage roots. A separate Team folder for each child would add administration without improving independence from user accounts. Subfolder permission exceptions must still be translated safely; nesting is not permission to widen access.
Implementation consequence: validate centrally managed destination storage and supported access controls before transfer. Read-only checks reject destinations without verified group-mount properties. Account-deletion independence, provisioning and effective access still need isolated integration tests; they are not established by a successful connection check.
Transfer mechanism: decision and rationale
Decision: Cloud Sync transfers files and folders directly through Nextcloud WebDAV. Use the supported management interfaces separately to configure Team folders, users, groups and permissions. Do not use desktop synchronization client processes as the service transfer engine.
Reason: direct WebDAV lets Cloud Sync control individual operations, retries, verification and the stop required before failover. It reuses the existing batch-transfer code and avoids managing separate desktop client processes and local synchronized directory trees per customer.
File and folder paths are decoded relative names. Literal # and % characters are supported and encoded by the Graph/WebDAV URL builders; percent-like text in a name is not decoded into a path separator. Absolute paths, traversal, backslashes, control characters and unsupported colon/question-mark characters remain blocked. Unsupported-character errors identify the path and character in the existing inline feedback and automatic run/audit evidence, without adding a status block. Historical reports remain unchanged.
WebDAV is the transfer protocol, not the synchronization policy. Cloud Sync must implement change tracking, reliable deletion handling, scheduling, pause/resume and recovery decisions. Large-file transfers can use Nextcloud chunked uploads, with compatibility verified against the supported target version.
The technical account accesses the centrally managed Team folders. A username in the WebDAV path identifies the access context; it does not authorize falling back to that account's personal storage. Destination storage type must be checked before transfer.
Implementation status: the inherited WebDAV client is reused. Persistent round coordination, retries, completed-item resume and failover stopping have deterministic local adapter tests. The service worker supports manual additive content runs and read-only checks. Built-in continuous content and permission adapters require certificate registration and runtime server compatibility checks; external integration remains unverified.
Transfer security
Files pass through the Cloud Sync worker from SharePoint to Nextcloud; this is not a direct SharePoint-to-Nextcloud transfer. HTTPS protects the Graph download and the Nextcloud WebDAV upload. The worker needs the file bytes briefly in memory to verify and upload them.
Saved connections and protected recovery copies are encrypted locally. Encryption of regular files stored in Nextcloud depends on the customer's Nextcloud and storage configuration; Cloud Sync does not claim to provide or verify that encryption at rest.
Manual folders and files
Clear run history asks "Are you sure you want to clear run history?" before clearing finished run summaries and their content details from Synchronization. Active runs remain visible and new runs appear normally. Clearing affects only the current customer display; Reports and audit, audit exports, transfer resume evidence and scheduler state are retained. The action records run_history.cleared in the audit history. Reason: let administrators tidy the operational view without deleting evidence or changing background work.
Synchronization feedback stays to the right of its action button in the same row. Long progress and completion messages wrap inside the feedback column, including on narrow screens. Use one inline status per option and retain it when Start sync changes to Stop sync, Stopping... or Start sync. Reason: keep feedback visibly attached to the action that produced it. Reports, run results and audit exports retain their existing content.
Clearing run history also removes finished Copy Once feedback beside Start copy, including Warning or Error references to the hidden details. Running feedback remains visible, and a new run supplies fresh feedback. Original outcomes remain available in Reports and audit and exports. Reason: an inline result must not refer to details that the user has cleared from Synchronization.
Run history shows one compact visible row per run when collapsed: Started, Option, Folders, Files, Outcome and Details. Folders and Files headers use a mouse-over tooltip, "Added / Deleted / Updated or Moved", to state the fixed count order. Each run cell shows all three counts in the tooltip order, for example 3 / 5 / 4. A rename or move is one Updated/Moved change, rather than an ambiguous addition and removal. Copy Once counts new target content as Added; a source folder that is created in Nextcloud also counts as Added, while a folder already there does not count as a change. Unchanged existing items remain in expanded details. Place Show details in the separate Details column immediately after Outcome; the button changes to Hide details when expanded. Duration, transferred size and throughput appear in the expanded details. Historical runs without retained item data show - without implying an error. Expanding reveals a row spanning all six columns directly below the summary; collapsing hides that row completely. Each run expands independently, with keyboard operation and an accessible expanded state. Detail filter and pagination links reopen their selected run. Reason: show the content and type of each run change first while keeping performance measures available on demand. Report content, exports and stored evidence are unchanged.
When a customer starts, stops or restarts synchronization, Run history adds a Sync entry with Started by user, Stopped by user or Restarted by user. These entries have no content counts or expandable details, and explain intervals without synchronization. Clearing Run history hides them with the other visible run history entries; audit evidence and exports retain the underlying user action.
All application screens and generated reports display timestamps in the Europe/Amsterdam local time zone. Stored records and audit exports retain their UTC timestamps to preserve interoperable evidence and unambiguous calculations.
Synchronization action feedback is compact: Running: followed by a short current activity, Completed, Waiting, Stopping or Stopped; Warning and Error refer to run details. A safe item-level warning, such as a locked target file after retries, does not stop the round: other folders and files continue, the item is retained for the next scheduled sync, and the task shows Waiting with items needing retry. An error means that safe synchronization cannot continue, so the task stops for administrator resolution and a later user restart. Each run history row has expandable details with separate file and folder counts, warnings/errors first, filters and 50-item pages. Copy Once skips an existing file normally only after matching prior verified evidence to the current source version and checking target identity, size, dates and bytes; changed or unverified targets remain warnings and are never overwritten. Completed per-item run details expire after a configurable 90 days by default, including in exports. Compact summaries and performance remain; audit records follow the separate audit retention policy (12 months by default). Active, warning/error and legacy unbound copy evidence is retained. Latest verified copy baselines, synchronization journals and recovery evidence remain protected. Clearing visible history only hides rows. Reason: keep action feedback readable, distinguish expected repeat copies from problems and bound disposable history without losing operational evidence. Local tests cover this behavior; live compatibility remains unverified.
Start copy and Start sync show Running: followed by a short activity such as Scanning selected files, Checking source permissions or Synchronizing and verifying files. The same inline feedback is used on initial page load and during polling, and stays beside the initiating controls. Reason: show that work is progressing and what it is doing without adding a second status block. Detailed outcomes remain in automatic run results and audit exports; historical reports are unchanged.
During file processing, Start copy and Start sync show a compact percentage and processed-file count beside their controls, for example Running: Copying and verifying items - 42% (84/200). Discovery and permission checks show only their activity until the relevant total is known. Copy progress covers files in its saved run plan, including verified skips and resumed results, and excludes folders. Sync progress covers file changes planned for the current round, including already completed operations on resume; unchanged files require no transfer and are outside this total. Retries count a file only once. Processed files can include failures, so progress is not a success score, byte percentage or remaining-time estimate. Active or unsuccessful processing is capped at 99%; 100% appears only after successful final verification, as Completed for Copy Once or Waiting for Sync. Empty file plans keep activity text without a percentage. Detailed run results and optional audit exports retain these counts automatically. A time-based wait bar appears only while an enabled continuous task is waiting for its scheduled next check; it counts down to that check and is hidden while work is queued, running, stopping or blocked. A Sync Now button beside that bar queues an immediate new synchronization only while the task is waiting; it never interrupts or overlaps a running round, and the request is recorded automatically. Historical evidence is unchanged.
Place the action controls directly below each synchronization option title, before explanatory text. Under Copy Once, label the button Start copy. Under Continuous synchronization, use Start sync and Stop sync; keep Stopping... while stopping safely. The titles supply the mode context without repeating it in the button. Keep each existing inline status beside its controls. Run history Option values remain Copy Once and Sync; reports and exports retain the same operation names and evidence.
Synchronization presents Copy Once on the left and Continuous synchronization on the right as two equal-width options. On narrow screens they stack with Copy Once first. Each option keeps its own controls and inline status; shared run history and results remain below. Reason: make the two operating modes easy to compare without duplicate progress blocks.
Copy once performs one background copy run and ends when complete; it does not start continuous synchronization. Later source changes require another manual run, and existing target files are not updated. Scheduled checks remain read-only. Run history shows one summary per Copy Once or Sync run, with Option immediately after Started. Read-only connection checks appear in Reports and audit and remain in audit exports. Run history and Content run results show Duration (HH:MM:SS), Transferred (decimal units) and Throughput (decimal units per second). Duration covers the recorded run start to finish, including discovery, checks, retries and pauses between resumed batches. Transferred counts acknowledged file uploads once, including uploads with verification issues, but excludes folders, conflicts and unconfirmed attempts. Throughput is transferred bytes divided by total duration; active runs and zero-duration runs show no final throughput. Read-only checks have no transfer throughput. Audit exports include duration_seconds, bytes_transferred and throughput_bytes_per_second automatically. Existing historical reports are unchanged. Run history and Content run results show Duration (HH:MM:SS), Transferred (decimal units) and Throughput (decimal units per second). Duration covers the recorded run start to finish, including discovery, checks, retries and pauses between resumed batches. Transferred counts acknowledged file uploads once, including uploads with verification issues, but excludes folders, conflicts and unconfirmed attempts. Throughput is transferred bytes divided by total duration; active runs and zero-duration runs show no final throughput. Read-only checks have no transfer throughput. Audit exports include duration_seconds, bytes_transferred and throughput_bytes_per_second automatically. Existing historical reports are unchanged. Reports and audit contains recorded events and the optional Export audit and run results action; Existing export fields and historical evidence remain unchanged; rounds include an additional option field (Copy Once or Sync, null for read-only checks).
Continuous controls: Start synchronization performs the initial copy and then keeps the same saved scope up to date. Show a compact state beside the controls: Running: followed by a short current activity, Waiting, Stopping, Stopped or Error with a short reference to run details. Keep detailed activity in expandable run history and show last successful synchronization and the next check in the option context without duplicate status blocks. Stop synchronization stops new transfers, safely finishes in-flight transfers and saves progress while retaining the target copy; show Stopping... until stopped. Start synchronization after stopping begins a fresh round and verifies recorded copies against the current target. Prevent concurrent manual copying and continuous synchronization for the same selection. Enable these controls only after continuous updates, safe overwrites, permissions and recovery integration are implemented and tested. Reason: clearly distinguish a one-off copy from the continuity service and provide visible, controlled operation.
One durable synchronization task is allowed per customer, using the saved scope and single target. Start schedules an immediate run; subsequent checks default to every 15 minutes, configurable in Settings. Each execution has its own automatic run record. Stop cancels future execution and retries, finishes in-flight work safely and retains completed progress. Closing the browser does not stop the worker; service restarts recover enabled tasks without restarting deliberately stopped tasks. Stop before editing connections, scope or destination names. Copy once is unavailable while synchronization is enabled or stopping. Missed intervals coalesce into one catch-up run. Reason: one task provides simple controls and avoids overlapping transfers. Task control, scheduling and conditional content-adapter behavior have local tests. The default web service and worker install the continuous adapter. Connections can generate a permission-check certificate and keep its private key encrypted; the customer administrator must register the public certificate and consent to selected-site and directory access in Microsoft 365. Start requires a valid saved certificate. Each new configuration runs isolated synthetic conditional-write, recovery-readback and effective read-only access checks before transferring source files. Unsupported source rights or failed checks block the run. Local fixtures verify these integrations; external Graph/Nextcloud compatibility remains unverified until the customer environment passes its checks. Independent MFA, collaborative editing and verified recovery remain separate failover requirements. Supported uniform internal group rights cover whole libraries and selected roots; custom, direct-user and differing nested permissions block safely.
Manual folders and files: Copy once on Synchronization copies the current saved scope, including empty folders and new descendants, to verified Team folders, automatically creating missing managed library folders. Connections and managed storage are checked automatically. A missing or invisible Team folder is reported with its destination path and setup guidance, separately from a missing WebDAV account root. Employee users and SharePoint permissions are not processed; existing target access remains in effect. This user-approved interim step does not establish failover readiness. Verified existing copies of the same source version are skipped; changed or unverified targets produce warnings and are never overwritten; deletion and retention integration remain outside this step. Background runs use bounded batches, item retries and durable completed-item resume. Upload, file ID, size and source date verification are recorded separately, with source attribution and automatic audit exports. The scheduler continues to run read-only checks. Direct conditional WebDAV uploads are used; server upload limits and large-file compatibility require live validation.
Short synchronization option descriptions
Keep the descriptions below synchronization controls brief. Copy Once says: Copy the selected files and folders once. Existing files and permissions are left unchanged. Continuous synchronization says: Keep the selected files and permissions up to date. Missing folders are created automatically. Below Continuous synchronization, add the short policy explanation: Confirmed SharePoint deletions are mirrored automatically. If SharePoint is unavailable or cannot be read completely, the Nextcloud copy is preserved and synchronization retries automatically. Retain the configured interval, Settings link, last successful sync and next check as compact context. Keep concrete configuration blockers and one inline action status. Technical provisioning, baseline verification, recovery and compatibility details belong in About Cloud Sync and automatic run/audit evidence, not in lengthy instructions below the buttons. This text change does not alter transfer rules or historical reports.
Starting, stopping and automatically restoring folders
Start sync enables the service and schedules a new round with current source, target and permission checks. Stop sync disables future rounds and stops active work safely; show Stopping... until finished, then Start sync again. Preserve and verify unchanged copies without blindly replaying an old work list. Copy Once is optional and is never a prerequisite. If a previously used Team folder is missing, administrator management API inventory must confirm deletion rather than lost access or a rename. Synchronization automatically creates missing Team folders, including previously used folders that were deleted. No separate recovery button or Copy Once run is required. After complete source and permission discovery, archive the affected baseline, operations, journals and managed-folder/compatibility evidence before rebuilding managed storage and copying the current source. Retain other libraries, historical runs and encrypted recovery copies. Recheck target absence immediately before archiving; changed, hidden, renamed or incompletely inventoried targets block safely. Automatic folder restoration evidence appears in Reports and audit and optional exports. Local tests do not certify live compatibility.
Automatic managed Team folder creation
Copy once automatically creates a missing managed Team folder after source discovery completes. It uses the Nextcloud Group folders management API and requires the configured technical account to be a Nextcloud administrator with management API access. For each newly created folder, Cloud Sync creates a dedicated technical group containing only that existing account and grants read, write and create access (no delete or share). No employee accounts, memberships or SharePoint permissions are synchronized. Existing accessible Team folders are reused without changing their rights. Hidden existing folders, personal storage, name collisions, unexpected access and unconfirmed creation outcomes block transfer rather than creating duplicates or broadening access. Persisted folder IDs and setup progress support retries; an ambiguous creation response requires administrator review. Optional root grouping is passed as the managed mount path and must pass exact path and WebDAV managed-root verification before content transfer. Creation, technical access and verification results appear automatically on Synchronization, Reports and audit, and in the audit export. Connection checks and scheduled checks remain read-only. Actual server compatibility still requires live validation.
After technical access is configured, the worker checks WebDAV mount visibility up to four times with fresh HTTP sessions and waits of 1, 2 and 4 seconds between checks. Only a missing resource is retried; denied access, personal storage and invalid managed-mount evidence remain blockers. Progress stays beside Copy once. A persistent failure preserves the created folder and its ID for the next run and reports the visibility problem without assuming that a top-level folder has a root-layout error. Successful verification records the check count in both screen results and audit exports. No additional folder or access mutation occurs during these visibility checks.
File timestamps and source information: decision and rationale
Decision: preserve the SharePoint file creation date as the Nextcloud creation date and the SharePoint last-modified date as the Nextcloud last-modified date on each synchronized update. Use the service-level SharePoint timestamps as the source of truth rather than client-supplied local file-system timestamps.
Record synchronization time separately in Cloud Sync. Retain the source creator and last editor as source information in Cloud Sync; do not present them as the identities that performed the Nextcloud upload.
Reason: employees must recognize when a document originated or changed. Replacing those dates with the transfer time would make an initial copy look like newly created or edited content and would undermine sorting and comparison.
Read the dates back from Nextcloud after transfer and verify that they were preserved, including chunked uploads. Validate support and timestamp precision against the actual target version. Unsupported or mismatched dates must be visible as a verification issue, not silently reported as successful preservation.
During failover, Nextcloud edits receive their actual current modification times. Keep the last synchronized source timestamps separately for recovery; do not overwrite failover edits with old source dates.
These basic timestamps and source identities are an explicit exception to the earlier exclusion of additional metadata. Arbitrary SharePoint business fields remain outside scope. Folder timestamp behavior has not been decided by this file-specific requirement. Creation and modification upload headers and strict date readback are implemented and locally tested; real server behavior, including chunk assembly, remains unverified.
Users, groups and access rights
Relevant users and groups are created automatically or linked to existing Nextcloud identities. Group memberships and confirmed access revocations are kept up to date.
The first release uses controlled group permissions per selected library or folder, distinguishing readers from employees allowed to edit during failover. It does not promise an exact translation of every SharePoint permission arrangement.
Source permission exceptions must be resolved before affected content is made available. Unsupported or uncertain permissions must never be silently widened. Guests and public sharing links are excluded from automatic provisioning.
Limited Access and the recognized built-in Web-Only Limited Access role are navigation permissions, not document grants. Cloud Sync excludes the latter only when both its numeric role ID (1073741833) and RoleTypeKind (9) match; localized names do not control recognition. These assignments create no target group or document access. Actual content grants and descendant permission exceptions remain subject to the supported mapping checks; navigation-only evidence cannot establish access. This corrects a false blocker without broadening permissions.
Employees receive and test an independent Nextcloud sign-in method with MFA before an outage. Activation and recovery must not depend solely on Microsoft sign-in or Microsoft 365 email being available during the outage.
Normal operation
SharePoint is authoritative. Employees have read-only access to the Nextcloud copy; the synchronization service can update it. SharePoint read-only users must not gain editing rights during failover.
Cloud Sync checks for changes every 15 minutes by default, configurable per customer. This is a polling interval, not a guarantee that every change is available within 15 minutes. Large changes, throttling or connection failures can increase the actual delay.
Background workers operate independently of browser sessions. Only one synchronization round runs per customer at a time. Work resumes safely from saved progress after interruption. Different customers can run concurrently with bounded capacity so a large customer does not block others.
Manual failover and collaborative work
An authorized customer administrator activates failover manually. Source synchronization must stop before the agreed editing rights are enabled. A connection error never triggers automatic failover.
Employees can add and edit documents in Nextcloud. Collaborative browser editing is supported where a working online office environment is provided by the Nextcloud operator. Its independence from Microsoft and actual collaborative editing are tested during onboarding.
Cloud Sync records additions, edits and deletions during failover for later review. Failover changes are preserved until the administrator explicitly confirms they have been handled during recovery.
Guided recovery to SharePoint
The administrator asks employees to stop editing in Nextcloud before reconciliation. Cloud Sync provides an overview of files added, changed or deleted during failover and flags files also changed in SharePoint.
The administrator reviews differences and manually returns the desired changes to SharePoint. Automatic reverse synchronization and automatic conflict merging are outside the first release.
Normal synchronization resumes only after verification and explicit administrator confirmation. The recovery overview remains available in the history and as an optional report export. SharePoint becoming reachable is not permission to overwrite unreconciled Nextcloud changes.
Recovery retention
Deleted content and previous content of overwritten files remain recoverable for 30 days by default, configurable per customer. Only authorized administrators can access this protected recovery area; employees see the current copy.
Retained content counts towards storage usage. The ordinary retention window must not discard unresolved failover changes: those remain until the administrator confirms recovery handling.
Incomplete scans and source outages
Continuous synchronization treats SharePoint as authoritative for every selected in-scope file. It adopts an existing file when SHA-256 hashes of the actual SharePoint and Nextcloud contents match, regardless of which process placed it there, prior copy evidence, file ID or differing timestamps. Matching files are not uploaded again and their current target identity and hash verification are recorded automatically. When contents differ, Cloud Sync queues a guarded conditional replacement from SharePoint: it rechecks the source version and target identity, retains the previous target bytes in protected recovery storage, overwrites with If-Match, then verifies the target identity, size and dates. A source or target change during those checks blocks the round without an overwrite. Managed storage and complete source/permission discovery remain required. Unreadable files block the round for a later retry. Automatic audit events record queued and completed replacements. Copy Once retains its separate existing-file rules. Local regression tests cover adoption, guarded replacements and changes during verification; live compatibility remains unverified.
An unreachable or incompletely read source is never evidence that files were deleted or access was revoked. Cloud Sync preserves the last confirmed copy and rights, marks the round incomplete and alerts the customer administrator.
Cloud Sync is a SharePoint mirror: reliably confirmed source deletions and access revocations are processed automatically, including large or deliberate deletions. Confirmed deleted source folders are removed from the verified target after their confirmed files are removed. No routine cleanup approval or deletion-count threshold is required. Backup is responsible for recovery from unwanted source deletions; the existing recovery-retention policy is separate from outage protection. Missing files in an unsuccessful or incomplete scan, denied access and an inaccessible library never authorize cleanup. A successful connection alone does not establish complete source discovery. The dashboard shows when files and rights were last verified, including uncertainty while the source is unavailable. Retries continue automatically; after complete source and permission discovery succeeds, mirroring resumes automatically unless failover is active. Failover remains a manual decision.
Status and notifications
The dashboard shows the last fully successful synchronization, actual synchronization lag and errors requiring action. File transfer and permission processing are shown separately: successful uploads alone do not establish failover readiness.
Administrators receive email when synchronization or permission processing is blocked, or when an active schedule has had no fully successful round for more than 60 minutes. The threshold is configurable. A recovery notification follows resolution.
Synchronization-lag alerts are suppressed during deliberate failover. Customers configure an additional notification address outside Microsoft 365 so broader Microsoft outages do not hide the notifications.
A safe item-level failure, such as a locked target file or a source item that cannot be read before any target mutation, is retained as Warning after normal retries. The round continues with other items and then shows Waiting — 1 item needs retry (with the actual count); the next scheduled synchronization retries it. Incomplete discovery, invalid scope, unknown target content, identity or ETag uncertainty, permission-validation failures and unconfirmed overwrite or deletion outcomes are Error conditions: the round stops, preserves the confirmed target copy and requires a new start after resolution.
Audit history and optional exports
Record who changes connections, scope and permission settings, who activates failover and who confirms recovery, together with synchronization outcomes. Service-administrator actions within a customer environment are recorded too.
Audit records are retained for 12 months by default and are exportable per customer. Do not record passwords, tokens or document contents in the audit log. Customers can view only their own records.
Checks, results and audit history are recorded automatically. No separate report-generation action is required at each step. Reports and audit provides existing results and optional exports; historical migration reports remain evidence of their original runs, not proof of Cloud Sync readiness.
Commercial scope and billing
Cloud Sync is intended to be a paid service. The first release includes a billing stub only: no payment processing or invoice generation. Pricing, subscription structure, allowances and commercial limits have not been decided.
Nextcloud hosting and its online office environment have an explicitly assigned operator. Including or pricing these services is a separate commercial decision. The synchronization interval is not a contractual recovery-point or availability guarantee.
Delivery boundary and next implementation work
The local service delivers authenticated customer administration, one-use invitations, customer-separated databases, encrypted credentials, the approved navigation, one target with optional root, source selection after discovery, browser-independent read-only checks, automatic audit with optional export, calendar-based audit retention and a billing stub. The unauthenticated migration handler is not mounted in the service; it remains a separate local compatibility command.
Tested components include source identity and deletion policies, incomplete-scan blocking, group-right and membership policies, a persistent resumable round coordinator, encrypted recovery copies, unresolved-change retention, failover/recovery transition guards and durable notifications with TLS mail delivery and retry. These components are not evidence of working live synchronization. Employee provisioning, authoritative source group translation and protected target recovery capture are integrated for supported configurations. External live validation, failover-change monitoring, independent MFA and office validation remain incomplete. SMTP delivery is not configured or live-validated. The service cannot activate failover. Manual additive content transfer and managed Team folder creation with technical-account access are available without employee permission synchronization; live integration remains unverified.
Hosting architecture, production security controls, secret storage, supported Nextcloud configurations, scale targets and contractual service levels still require technical validation or further decisions. Reuse controlled resumable transfers and evidence-based verification from the migration code where appropriate.