How to copy a personal Microsoft List to a SharePoint site safely

If a list under My lists has become important to a team, do not treat the job as a one-click move. Microsoft Lists can clone the list's columns, views and formatting into a SharePoint site, but that does not copy the list items.

The safest route is:

create the destination list from the existing list;
decide how much data fidelity you need;
copy the records with grid view, a spreadsheet or Power Automate;
rebuild and test anything connected to the old list; and
keep the source available until the new list is signed off.

That distinction matters. A copied list can look right while its attachments, rules, flows, form, permissions and history are still sitting in the old location.

Quick decision: which copy method should you use?

What you need to preserve	Best starting route	What it does not preserve automatically
Columns, views and formatting only	From existing list	Items, attachments, version history, most rules, flows and a customised Power Apps form
A small number of simple rows	Clone the structure, then use Edit in grid view	Attachments, item history, original IDs and dependent automation
Flat tabular data that can tolerate cleanup	Export to Excel or CSV, then create/import at the destination	Attachments, views, JSON formatting, relationships, history and reliable recreation of complex column types
A controlled, repeatable item copy	Power Automate with an explicit field map	Dependencies outside the flow; attachments need separate actions
Complex lookups, forms, permissions, history or a business-critical solution	A planned migration using specialist tooling or an engineered provisioning process	Nothing should be assumed—prove each requirement with a pilot

If all you need is an empty copy of the design, use From existing list and stop there. If people already rely on the records, read the rest before changing anything.

What Microsoft copies—and what it leaves behind

Microsoft's current create-from-existing-list guidance is unusually clear:

the new list receives the source list's columns, views and formatting;
the source list's content is not copied;
a source with more than 80 views cannot be used by this route; and
if the source contains automated rules, only the first two rules are included.

Treat the result as a new list built from the old design, not the same list in a different place.

That wording also explains why “copy” and “move” are easy to confuse. There is no general Microsoft Lists button that relocates a complete personal list solution, with all its data and dependencies, into another SharePoint site.

Before you copy anything, inventory the source

Open the personal list and write down what is actually there. This is the part people skip because the list appears simple on screen.

Check:

every column's display name, internal name and type;
required fields, default values, validation and unique-value settings;
choice values and whether multiple selections are allowed;
person, lookup and managed-metadata columns;
calculated columns and their formulas;
public and personal views, filters, sorting and grouping;
column and view JSON formatting;
item attachments and image columns;
automated rules and Power Automate flows;
whether the form was customised with Power Apps;
versioning, approvals, item-level permissions and retention requirements;
Teams tabs, pages, apps, reports or bookmarks that point at the old list; and
the number of source items and attachments.

Also export a flat copy of the data before the change. It is useful for reconciliation, but do not call it a complete backup: Microsoft's manual migration guidance says list attachments are not saved by an Excel export, and properties, permissions and relationships can be lost.

Method 1: clone the list structure with From existing list

Use this when you want the destination list to start with the same columns, views and formatting.

Open the Microsoft Lists app, or open the destination SharePoint site.
Select New list.
Select From existing list.
If the picker shows My lists, select the personal list. Otherwise, select the available source location and list.
Give the new list a clear name and description.
Under Save to, choose the destination SharePoint site.
Create the list, then open it at the destination and inspect the result.

Microsoft documents the same creation experience from Lists, SharePoint and Teams. However, it does not guarantee that every tenant, entry point or rollout will display a personal list in the source picker.

If My lists is missing, do not follow an old article promising that a different sidebar will trigger a secret backend route. Confirm that you are signed into the correct account, open the personal list directly in Microsoft Lists, and try the current New list > From existing list experience. If the source still is not offered, use one of the data-copy routes below or ask your SharePoint administrator to help with a controlled migration.

Administrators can disable creation of new personal lists, so tenant experiences can legitimately differ.

Validate the empty destination

Before copying records, compare:

column count and types;
required and unique fields;
lookup targets;
default and calculated values;
the important views;
JSON formatting; and
rules.

Do not assume a lookup or person column is working because its heading exists. Open its settings and create one test item.

Method 2: copy a small, simple dataset in grid view

For a short list containing ordinary text, numbers, dates and simple choices, grid view may be enough.

Create and validate the destination structure first. Open the source and destination lists in Edit in grid view, copy a small set of rows, then check the destination before continuing.

This route is suitable only when:

there are few enough rows to check manually;
attachments are not required;
person, lookup and managed-metadata fields are absent or have been tested;
losing the original item IDs and history is acceptable; and
nobody is changing the source while you copy.

Test dates, leading zeroes, multiline text and multi-select choices. A pasted value can look plausible in the grid while being stored in the wrong column type or rejected after save.

Method 3: use Excel or CSV for flat data

Microsoft Lists can export the current view to Excel or CSV, and it can create a list from a spreadsheet.

That makes a spreadsheet useful when the source is essentially a table and you are happy to rebuild the SharePoint-specific parts.

Use this sequence:

Create a source view containing every field you intend to carry across.
Export that view to Excel or CSV.
Inspect the file for missing or flattened values.
At the destination, create a list from the file or paste the checked rows into a structure you cloned earlier.
Review every inferred SharePoint column type before inviting users in.

Microsoft describes the Excel export as a one-way connection: refreshing Excel can pull newer values from the source list, but edits in the workbook are not written back to that list. CSV is a disconnected snapshot and currently has a documented export maximum of 30,000 rows.

Neither route preserves attachments. It also should not be trusted to recreate lookups, people, managed metadata, list formatting, rules, permissions, original IDs or version history.

Excel is a useful transport for flat values. It is not a full-fidelity SharePoint migration format.

Method 4: copy items and attachments with Power Automate

Use Power Automate when you need a repeatable copy, explicit field mapping or attachments, and the solution is still small enough to test and operate safely.

1. Prepare the destination

Clone or build the destination schema first. Add a column such as SourceItemId to store the original list item's ID.

That source key makes the flow rerunnable. Before creating an item, the flow can check whether that source ID already exists at the destination and update or skip it instead of creating a duplicate.

Microsoft's documented copy-items flow pattern requires a stable value that uniquely identifies corresponding records. A title or person's name is a poor key if it can change.

2. Build a one-time migration flow

For a controlled one-time copy, use a manual trigger and this shape:

Get items from the personal source list.
For each source item, look for its SourceItemId in the destination.
If it does not exist, use Create item and map each required field.
If it exists, either skip it or update only the fields approved for reruns.
Record success or failure in a migration log.

Do not point two automatic flows at each other in an attempt to create an instant two-way sync. Microsoft warns that the documented copy pattern is one-way and that paired updates can create a loop.

3. Configure item retrieval deliberately

The SharePoint Get items action does not return an unlimited dataset by default. Microsoft's Get items guidance documents a default of 100 items and a 5,000-item list-view threshold for a request.

For anything beyond a small list:

turn on pagination where appropriate;
use indexed columns and a server-side Filter Query to work in controlled batches;
keep the source ID in the destination;
handle throttling and failed actions; and
reconcile the final count rather than trusting a green flow run.

The 5,000-item threshold is not a promise that every 5,000-item migration will work in one run. Column complexity, filters, connector limits and tenant load still matter.

4. Map complex fields instead of guessing

Review these fields separately:

Person: confirm that every account resolves in the destination tenant and that single/multiple values map correctly.
Lookup: recreate or migrate the lookup source first, then point the destination column at the correct list.
Choice: make sure destination choices exist before writing values.
Managed metadata: verify term-set access and the values created at the destination.
Calculated: migrate the inputs and let the destination calculate; verify the formula and result.
Required and unique fields: populate them in the correct order and handle duplicates explicitly.
Multiline rich text: check the stored result, not only the flow designer preview.

Treat destination items as new records. Do not promise that the original item ID, author, created/modified timestamps or version history will survive a Create item action.

5. Copy attachments as a separate branch

Create item does not bring its attachments with it.

After the destination item has been created:

use Get attachments with the source item ID;
loop through the returned attachments;
use Get attachment content for each file; and
use Add attachment with the newly created destination item ID.

Those are documented actions in the SharePoint connector reference.

Log attachment failures separately from item failures. Otherwise a run can report that an item was created while its evidence file is missing.

What will not follow the list automatically

Power Apps customised forms

A Power Apps-customised SharePoint form is a separate dependency. Microsoft says there is no automated method to copy an integrated form between environments.

Plan to rebuild or reconnect the form, update its data source and test new, view, edit, save and cancel behaviour at the destination.

Power Automate flows and rules

Inventory every flow that reads or writes the personal list. Update its site address, list name, connection ownership, trigger conditions, field mappings and links.

Remember that From existing list includes only the first two automated rules. Recreate the rules you still need and test them once each. Do not leave both source and destination automation active unless the cutover design explicitly requires it.

Lookups, permissions and links

Lookups may still point at a source list, or may need to be recreated against a related destination list. Permissions should be designed for the destination site's owners and members rather than copied blindly from a personal workspace.

Update Teams tabs, SharePoint pages, bookmarks, reports and apps that contain the old URL.

For repeatable list structures, use the current admin template route

Old advice often says to save a list as an .stp file and upload it elsewhere. That is not the default route in this guide.

If an administrator needs the same approved list structure across many sites, Microsoft's current approach is custom list templates built with list designs and site scripts. Use that for governed, repeatable structure—not as a promise to migrate live records and dependencies.

Validation, cutover and rollback

Do not delete the personal list when the copy finishes.

Pilot first

Use a small but awkward sample containing:

blank and required values;
multi-select choices;
a person field;
a lookup, if used;
rich text;
an attachment; and
a record that has been edited more than once.

If the pilot cannot reproduce the required result, change the migration method before copying the full list.

Reconcile the destination

Check	Evidence to capture
Structure	Column types, settings, internal names where dependencies require them, views and formatting
Data	Source count, successful destination count, skipped count and failed count
Attachments	Attachment count plus sampled filenames, sizes and files that open
Behaviour	Each rule, flow, form action, lookup and calculation tested once
Access	Owners, members, visitors and any item-level permission behaviour
Entry points	Teams tabs, pages, apps, reports and saved links open the destination

Counts are necessary, but not sufficient. Spot-check the fields most likely to flatten or rebind: people, lookups, rich text, dates, calculated values and attachments.

Cut over once

Agree a short period when people stop editing the source. Run the final copy or delta, reconcile it, then switch links and automation to the destination.

Make the source read-only for ordinary users and add a clear notice pointing to the new list. Keep it available for the agreed recovery period.

Roll back without losing work

If the destination fails validation, restore the old links and source access, stop destination automation and investigate from the migration log. Because the source was retained, rollback is a routing decision rather than an attempt to reconstruct deleted records.

Only retire the personal list after the destination owner has signed off the data, attachments, access and connected processes.

Frequently asked questions

Does From existing list copy the data?

No. Microsoft says it copies the list structure—including columns, views and formatting—but not the original content. Copy the records separately.

Can I move a personal Microsoft List directly to a SharePoint site?

There is no general one-click move for a complete list solution. If the personal list appears in From existing list, you can clone its structure to the destination, then migrate and validate the data and dependencies.

Are attachments copied with the list items?

Not by the structure clone or an Excel export. In Power Automate, use Get attachments, Get attachment content and Add attachment after creating the destination item.

Will my flows, rules and Power Apps form still work?

Do not assume so. Only the first two automated rules are included by From existing list. Flows need their source references and field mappings checked, and Microsoft says there is no automated method to copy a SharePoint-integrated Power Apps form between environments.

What if the list contains more than 5,000 items?

The 5,000 figure is a list-view/request threshold, not a complete migration plan. Power Automate Get items defaults to 100 records. Use indexed filters, pagination and controlled batches, or choose specialist migration tooling when the required fidelity or operational risk is beyond a flow.

Keep the new list owned, supported and findable

Moving a personal list solves the location problem. It does not assign ownership, document the automation or keep the solution healthy.

If you manage SharePoint and Teams for other people, join SharePoint & Teams Admins for practical guidance on lists, permissions, governance and the Microsoft 365 changes that affect your tenant.