Another often asked question is a ‘How to change SPListItem Created/Modified date’. Such task occur when you importing documents to the SharePoint from another source when you want to save authorship and time information.
To update Created and Modified date you can use SPListItem indexer to modify infomation and call Update() to save changes.
To modify CreatedBy and ModifiedBy properties, you can use SPListItem indexer to modify fields with internal names Author and Editor. But you should convert SPUser object into string with following format “{userId};#{userName}”
Example you can find below:
public void ApplyMetadata(SPListItem item, DateTime created, DateTime modified, SPUser createdBy, SPUser modifiedBy)
{
item["Created"] = created;
item["Modified"] = modified;
item["Author"] = GetStringByUser(createdBy);
item["Editor"] = GetStringByUser(modifiedBy);
item.Update();
}
private static string GetStringByUser(SPUser user)
{
return user.ID + ";#" + user.Name;
}
Sergey Tihon's Blog 
Regarding you post in line 07 item[“Modified”] should be item[“Editor”]
Fixed. Thank you.
You should take part in a contest for one of the most useful websites on the
internet. I most certainly will highly recommend this site!
Good blog you have got here.. It’s difficult to find excellent writing like yours these days. I really appreciate individuals like you! Take care!!
I’m a rookie at PowerShell. Is there a PowerShell script that can do this?
PowerShell should looks almost the same.
Either this post is plainly WRONG or else ScarePoint just shows why it deserves that nickname.
The docs for SPListItem.Update say nothing about how the magic last modified field is maintained. But it’s supposed to be set when we call Update, and that also makes sense if the field is really supposed to say when the item was last modified!
Hence one ought to expect that your call to item.Update would result in field “Modified” being set to the time of the update, and your manual setting some other value should be irrelvant.
Looking at the docs for SPListItem.SystemUpdate further strengthens this suspicion: “Updates the database with changes made to the list item without changing the Modified or Modified By fields.”
(https://msdn.microsoft.com/EN-US/library/office/microsoft.sharepoint.splistitem.systemupdate.aspx)
Although MSDN says nothing about Update having these side effects, it is difficult to make sense of the SystemUpdate doc if those side effects don’t exist.
Maybe ScarePoint tries to “help” developers and have some way of detecting whether the “modified” field was itself modified, and if so, behaves differently? All without documenting any of it, of course. That would be quite typical.
I’ve programmed nearly all my life, for 30 years now, and I can honestly say I have NEVER seen a framework as buggy, illogical and ill-performing as SharePoint gain widespread use. Even VBA code in Excel spreadsheets, typically authored by people who don’t call themselves programmers, tends to be of higher quality than the spaghetti nonsense you find in SharePoint solutions….