Enumerating my method to handle any time out issue

I'm not familiar with Azure Functions and CosmosDb, so I won't review your code from API consumption perspective.

Here are my observations:

• FunctionNameAttribute: Please prefer nameof operator over hard-coded values
  • If you rename your class (from Function1) then the hard-coded value will not change with it accordingly
  • On the other hand if you need to refer Function1 elsewhere in your cloud application then create a static class where you store your constants
• collectionUrl: I think you don't need to create a separate variable for this, you can simply inline it
  • CreateDocumentQuery does have an overload which accepts an Uri

client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri("databaseName", "SourceCollection"),
    new SqlQuerySpec("SELECT * FROM c WHERE IS_DEFINED(c.ClassId)"),
    new FeedOptions { ... });

• feed.ExecuteNextAsync().Result: Please prefer async calls over blocking sync calls
• result.Count: As I said I'm not familiar with this API but I would suggest to do some checks on the FeedResponse object to make sure that your issued operation has succeeded before you start to consume it
• itemCount: As I can see it is unused so you can freely get rid of it
• (JObject)JsonConvert.DeserializeObject: Please prefer JObject.Parse to semi parse json strings
  • Please also bear in mind that this might throw exception (JsonReaderException) if not valid json is retrieved for whatever reason
• data["ClassId"]: Please prefer TryGetValue method over index operator in production code
  • You can examine data existence before you start to using it
• data["ClassId"].Value<string>(): You can convert the JToken to string with simple casting: (string)data["ClassId"]
• string.Concat: Please prefer string interpolation over explicit call of concat.
• data.Add(new JProperty ...): I think you don't need to create a JProperty explicitly, there is an other overload, which accepts the same as the JProperty constructor
• var data: Please try to use better naming than this, data is meaningless
• continuationToken != null: Please prefer string.IsNullOrEmpty over direct null check against string variable

UPDATE: How to use TryGetValue

ZZZSharePoint has pointed out that the provided link for TryGetValue is insufficient to put theory into practice. So, here is my suggestion how to apply that function onto this problem:

const string classIdFieldName = "ClassId", projectFieldName = "Project";
const string collectionName = "SourceCollection", partitionKeyFieldName = "PartitionKey";
            
var semiParsedFetchedRecord = JObject.Parse(doc);
if(!semiParsedFetchedRecord.TryGetValue(classIdFieldName, out var classIdField))
    throw new MissingFieldException(collectionName, classIdFieldName);

if (!semiParsedFetchedRecord.TryGetValue(projectFieldName, out var projectField))
    throw new MissingFieldException(collectionName, projectFieldName);

semiParsedFetchedRecord.Add(partitionKeyFieldName, $"{classIdField} | {projectField}");

• I've introduced several constants to make maintenance (and reuse) easier
• I've used JObject.Parse to get a semi-parsed json (I've renamed your data variable to express what's stored inside it)
• I've used TryGetValue to make data retrieval operation safe
  • I've used here the out var feature of C# to make the code more concise
  • otherwise we need to declare a JToken variable before the TryGetValue call
• I've used MissingFieldException to indicate that something expected is missing
  • ArgumentException might be a good choice as well
  • Or if we can ignore those records where the expected fields are missing then a simple continue might be okay as well
• Last but not least I've inlined the partitionKey calculation
  • Here I've took advantage of the JToken's explicit conversion operators